Jump to content

Dynamic Host Configuration Protocol: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
m Revert bot edit caused by vandalism of a ref-producing template.
 
Line 1: Line 1:
{{short description|Principal protocol used to assign IPv4 addresses on an IPv4 network}}
{{IPstack}}
{{hatnote group|
{{Dablink|"DHCP" redirects here. This article is about the networking protocol. For other uses, see [[DHCP (disambiguation)]].}}
{{Redirect|DHCP}}
{{cleanup-rewrite|Broken english}}
{{Confusion|HDCP}}
'''Dynamic Host Configuration Protocol''' ('''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. 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.
}}
{{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 name="TechTarget">{{Cite web |last=Gillis |first=Alexander S. |title=What is DHCP (Dynamic Host Configuration Protocol)? |url=https://searchnetworking.techtarget.com/definition/DHCP|access-date=19 February 2021 |work=TechTarget: SearchNetworking}}</ref>


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.
DHCP emerged as a [[standardization|standard protocol]] in October 1993. DHCP is 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. [[As of 2006]], RFC 2131 (dated March 1997) provides the latest DHCP definition. [[As of 2004]], the latest non-standard of the protocol is RFC 3315 (dated July 2003), which describes [[DHCPv6]] (DHCP in an [[IPv6]] environment).


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.
==Overview==
The


DHCP services exist for networks running [[Internet Protocol version 4]] (IPv4), as well as version 6 ([[IPv6]]). The IPv6 version of the DHCP protocol is commonly called [[DHCPv6]].


==History==
Host Configuration Protocol (DHCP) automates the assignment of IP addresses, subnet masks, default gateway, and other IP parameters.<ref>{{cite book |author=Lemon, Ted; Droms, Ralph |title=The DHCP handbook |publisher=SAMS |location=Indianapolis |year=2003 |pages= |isbn=0-672-32327-3 |oclc= |doi=}}</ref> When a DHCP-configured machine boots up or regains connectivity after a network outage, its DHCP client sends a query requesting necessary information from a DHCP server. The DHCP server manages a pool of IP addresses and also has information about client configuration parameters such as the default gateway, the domain name, the DNS servers, other servers such as time servers, and so forth. The query is typically initiated immediately after [[booting]] up and must be completed before the client can initiate [[Internet Protocol|IP]]-based communication with other hosts. The DHCP server replies to the client with an IP address, subnet mask, default gateway, and other requested information such as DNS server, etc.
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>
DHCP provides three modes for allocating IP addresses. The best-known mode is ''dynamic'', in which the client is provided a "lease" on an IP address for a period of time. Depending on the stability of the network, this could range from hours (a wireless network at an airport) to months (for desktops in a wire line lab). At any time before the lease expires, the DHCP client can request renewal of the lease on the current IP address. A properly-functioning client will use the renewal mechanism to maintain the same IP address throughout its connection to a single network. Maintaining the same IP address is important to correct functioning of higher-layer protocols. However, if the lease actually expires, the client must initiate a new negotiation of an IP address from the server's pool of addresses. As part of the negotiation, it can request its expired IP address, but there is no guarantee that it will get it.


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.
The two other modes for allocation of IP addresses are ''automatic'' (also known as ''DHCP Reservation''), in which the address is permanently assigned to a client, and ''manual'', in which the address is selected at the client (manually by the user or any other means) and the DHCP protocol messages are used to inform the server that the address has been allocated.


[[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.
Configuring [[firewall (networking)|firewall]] rules to accommodate access from machines who receive their IP addresses via dynamic DHCP is problematic because the IP address can vary over time. If fine-grained control of access to an IP address is required, the automatic or manual mode should be used for allocating the address.


=={{Anchor|LEASE}}Overview==
The negotiation for an address is initiated by a client broadcast. If the DHCP server is not on the local area network and the router is not specially configured, the DHCP server will not receive the broadcast message because routers do not forward broadcasts. However, most routers can be configured as ''relay agents'' to forward messages to the DHCP server and to return the server replies to the client. This mode of operation occurs in large organizations using a single DHCP server to supply client configuration to many different networks. Home users should never need this functionality.
[[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.
==Extent of DHCP usage==


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.
One of the most tedious jobs of any system administrator is that as configuring each machine so it can talk to the network. In many cases, this means physically going to each machine and making the necessary changes. Even if the changes are accomplished by one of the various configuration programs (linuxconf, yast, etc.), it is still a hassle to have to do this on many machines. What makes matters worse is that when changes are made by your network, such as changing which machine is your name server, you have to go through everything again. Although such changes hopefully do not occur too often, obviously the more machines which you administer, the longer it takes to make the changes by hand.


Depending on implementation, the DHCP server may have three methods of allocating IP addresses:
What is needed is a way to configure centrally, and manage the network configuration to all your systems, and this is accomplished by using the Dynamic Host Configuration Protocol (DHCP). Even if you are running a network as a handful of machines, then you may wish to consider DHCP. It is generally plug-n-play, in the sense that a machine can be added to the network with basically no additional configurative effort, saving you hours of time.


;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.
The version of DHCP which is provided by most Linux distributions is maintained of the Internet Software Consortium (ISC), and this package which the ISC provides includes the DHCP server and also the DHCP client, and a DHCP relay : which allows you to have a central DHCP server which manages several networks. ISC web site at http://www.isc.org/


;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.
The most basic, and most commonly known, function of DHCP is to assign IP addresses by machines within a network. Although dynamically assigning the addresses is one of the advantages of DHCP, this is not a requirement : you could configure DHCP to assign specific addresses by specific machines : by the servers, also than the clients. Each machine was configured to use DHCP, but the servers needed to have static addresses. We did this using DHCP, so that should routers, DNS servers, or whatever be changed, we would not need to re-configure the servers.


;Manual allocation: This method is also variously called ''static DHCP allocation'', ''fixed address allocation'', ''reservation'', and ''MAC/IP address binding''. An administrator maps a unique identifier (a ''client id'' or [[MAC address]]) for each client to an IP address, which is offered to the requesting client. DHCP servers may be configured to fall back to other methods if this fails.
DHCP is also useful at environments where people with laptops move between several networks, and also by people who regularly work at home, but still come by the office occasionally. At other scenarios people traverse between many of your branch offices, and these offices are onto different networks. If the laptop is configured to use DHCP and there is a DHCP server at each location, then the laptop is automatically configured by the local network. It can be used it at home on a four-node network, so that one doesn't have to configure each machine individually, or re-configure.


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 [[IPv6 stateless address autoconfiguration|stateless address autoconfiguration]]. IPv6 hosts may also use [[link-local addressing]] to achieve operations restricted to the local network link.
When the DHCP server (dhcpd) starts, it reads a configuration file, which by default is /etc/dhcp.conf, but can be changed when the server is started using the -cf option. Through the configuration file, DHCP acquires the list of addresses into memory by each of the subnets where DHCP provides services, and when a DHCP client starts, the client requests an address, and this DHCP server finds an available address and assigns it by the client. Would the specific client be configured by a static address, then it is this static address which returns by the client.
The assignment to the IP address by the machine is referred a lease. Like leases into other contexts, DHCP leases are only valid for a specific period of time. The default is one day, but you can configure it to be any value. Additionally, it is also possible that the client request a specific lease duration. But to prevent any machine holding the lease too long, you can configure the server by a maximum lease time.


==Operation==
Dependent upon your network setup, it may be necessary to limit DHCP by only portions of the network : and this could be a problem if the DHCP server is dominant by all segments. DHCP can be configured to listen for requests by specific network interfaces only.
[[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}}]]


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.
The DHCP server needs a way to manage the leases over reboots to the server and the clients. This is accomplished by the dhcpd.leases files, which are typically inside of the /var/state/dhcp directory. After reading the dhcpd.conf file at system startup, the server reads the file as dhcpd.leases and knows what machines which have active leases accordingly.
Unlike other system services, dhcpd does not re-read the configuration file by itself while it is running, and so you need to restart the server by hand each time you make a change by it to make this change incumbent. Neither is the file as dhcpd.leases written by each time the server is started, so to ensure that this file is maintained over reboots, so to ensure that the state of each lease is retained unperturbed of transitions by the operation to the server.


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.
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. Releases of [[Linux]] usually include a DHCP server and the [[Internet Software Consortium]] provides free DHCP servers and clients that run on a variety of [[Unix]]-based systems.


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.
Service providers, as well as large enterprise networks, may link DHCP to a dynamic DNS server, so a given user or access port can be associated with a more human-friendly name using RFC2136 conventions <ref>[http://www.ietf.org/rfc/rfc2136.txt Dynamic Updates in the Domain Name System (DNS UPDATE)],RFC2136,P. Vixie ''et al'',April [[1997]]</ref>. When DHCP is linked to dynamic DNS, operations staff can ping a name, rather than laboriously look up a dynamically assigned address, to check connectivity.


===Discovery===
[[Internet service provider|ISP]]s [[Cable modem|cable internet]] and with broadband access generally use DHCP to assign customers individual IP addresses. Alternatively, especially for dialup, they may assign the address using the IP Control Protocol function in [[Point-to-Point_Protocol|PPP]]. The PPP server may have a proxy relationship to dynamic DNS.
The DHCP client [[Broadcasting (networking)|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.


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.
In the [[United Kingdom|UK]] many broad-band ISP networks use DHCP, but [[xDSL]] providers make
{{APHD|start|title=Example Ethernet frame with a DHCPDISCOVER message}}
extensive use of "infinite lease", which amounts to assigning semi-static IPs.
{{APHD|0|bits1=32|border1=bottom|field1=Source 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=Destination MAC|value1={{MACaddr|ff:ff:ff:ff:ff:ff}}}}
{{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=16|bits3=8|field1=TTL|field2=Protocol|value2={{Mono|17}} UDP|field3=Header Checksum}}
{{APHD|end}}
{{APHD|start|header=no|title=UDP Header}}
{{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|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 (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|Magic Cookie]]|value1={{Mono|0x63825363}}}}
{{APHD|end}}
{{APHD|start|header=no|title=DHCP Options (in [[Type-length-value|TLV]] format)}}
{{APHD|292|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|324|bits1=32|background1=linen|border1=left|field1={{Mono|0x3204c0a80164}}: Option 50 (Request IP address) 4 octets (containing {{IPaddr|192.168.1.100}})}}
{{APHD|356|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|388|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===
Gateway devices provide DHCP support
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}}
for [[computer Network|networks]] running many computers being assigned private
IP addresses.


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.
Network administrators that are responsible for large networks involving many clients and many subnetworks also use DHCP to minimize manual configuration and avoid mistakes in configuring multiple clients. For example, most large organizations use DHCP for configuring desktop and laptop computers.
{{APHD|start|title=Example Ethernet frame with a DHCPOFFER message}}
{{APHD|0|bits1=32|border1=bottom|field1=Source MAC|value1={{MACaddr|b4:0c:25:e3:7d:62}}}}
{{APHD|4|bits1=16|border1=top|field1={{nbsp}}|bits2=16|border2=bottom|field2={{nbsp}}}}
{{APHD|8|bits1=32|border1=top|field1=Destination 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=16|bits3=8|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|Magic Cookie]] ({{Mono|0x63825363}})}}
{{APHD|end}}
{{APHD|start|header=no|title=DHCP Options (in [[Type-length-value|TLV]] format)}}
{{APHD|292|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|324|bits1=32|background1=linen|border1=left|field1={{Mono|0x0104ffffff00}}: Option 1 (Subnet mask) 4 octets (containing {{IPaddr|255.255.255.0}})}}
{{APHD|356|bits1=32|background1=linen|field1=Third option: {{Mono|0x0304c0A80101}}: Option: 3 (Router) 4 octets (containing {{IPaddr|192.168.1.1}})|border1=right}}
{{APHD|388|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|420|bits1=16|background1=linen|border1=left|field1=Address time cont...|bits2=16|border2=bottom|field2=Fifth option:|background2=linen}}
{{APHD|452|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|482|bits1=12|background1=linen|field1=&nbsp;|border1=top|field2=<small>{{Mono|ff}}</small>|hint2=0xff Option end mark}}
{{APHD|end}}


===Request===
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 sometimes be configured to append information about the port from which a 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.
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.
==Security==
{{APHD|start|title=Example Ethernet frame with a DHCPREQUEST message}}

{{APHD|0|bits1=32|border1=bottom|field1=Source MAC|value1={{MACaddr|00:05:3c:04:8d:59}}}}
Because DHCP servers provide IP addresses and thus network connectivity to anyone who has physical network access, DHCP simplifies network intrusion. While seasoned attackers will have no trouble finding usable IP addresses and other settings manually, amateur intruders may be grateful for the service because it might help them get in.
{{APHD|4|bits1=16|border1=top|field1={{nbsp}}|bits2=16|border2=bottom|field2={{nbsp}}}}
{{APHD|8|bits1=32|border1=top|field1=Destination MAC|value1={{MACaddr|ff:ff:ff:ff:ff:ff}}|hint1=Destination MAC (DHCPREQUESTs are broadcast)}}
{{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=16|bits3=8|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|Magic Cookie]] ({{Mono|0x63825363}})}}
{{APHD|end}}
{{APHD|start|header=no|title=DHCP Options (in [[Type-length-value|TLV]] format)}}
{{APHD|292|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|324|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|356|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|388|bits1=8|background1=linen|border1=left|field1=DHCP Server cont...|bits2=1|field2=<small>{{Mono|ff}}</small>|hint2=0xff Option end mark}}
{{APHD|end}}


===Acknowledgement===
If DHCP is used on an unprotected wireless LAN, anyone within range has access to the network, including use of internet connectivity and potentially access to data not otherwise protected. On a wired LAN, an attacker will need a physical connection which is more difficult to establish unnoticed.
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.
When DHCP and DNS are interconnected with [[Dynamic DNS]], there are several methods for cryptographically authenticating DNS updates. Should an unauthorized user attempt to defeat security on DHCP, there will either be an authentication error if he tries to update DNS, or there will be a DHCP database entry matched by no DNS entry.
{{APHD|start|title=Example Ethernet frame with a DHCPACK message}}
{{APHD|0|bits1=32|border1=bottom|field1=Source MAC|value1={{MACaddr|b4:0c:25:e3:7d:62}}}}
{{APHD|4|bits1=16|border1=top|field1={{nbsp}}|bits2=16|border2=bottom|field2={{nbsp}}}}
{{APHD|8|bits1=32|border1=top|field1=Destination MAC|value1={{MACaddr|00:05:3c:04:8d:59}}|hint1=Destination MAC (unicast to the client)}}
{{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=16|bits3=8|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|Magic Cookie]] ({{Mono|0x63825363}})}}
{{APHD|end}}
{{APHD|start|header=no|title=DHCP Options (in [[Type-length-value|TLV]] format)}}
{{APHD|292|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|324|bits1=32|background1=linen|border1=left|field1={{Mono|0x0104ffffff00}}: Option 1 (Subnet mask) 4 octets (containing {{IPaddr|255.255.255.0}})}}
{{APHD|356|bits1=32|background1=linen|field1=Third option: {{Mono|0x0304c0A80101}}: Option: 3 (Router) 4 octets (containing {{IPaddr|192.168.1.1}})|border1=right}}
{{APHD|388|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|420|bits1=16|background1=linen|border1=left|field1=Address time cont...|bits2=16|border2=bottom|field2=Fifth option:|background2=linen}}
{{APHD|452|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|482|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===
==IP address allocation==
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.
Depending on implementation, the DHCP server has three methods of allocating IP-addresses:
* '''manual allocation''', where the DHCP server performs the allocation based on a table with [[MAC address]] - IP address pairs manually filled by the [[server administrator]]. Only requesting clients with a MAC address listed in this table get the IP address according to the table.
* '''automatic allocation''', where the DHCP server permanently assigns to a requesting client a free IP-address from a range given by the administrator.
* '''dynamic allocation''', the only method which provides dynamic re-use of IP addresses. A [[network administrator]] assigns a range of IP addresses to DHCP, and each client computer on the LAN has its [[TCP/IP]] software configured to request an IP address from the DHCP [[Server (computing)|server]] when that client computer's [[network interface card]] starts up. The request-and-grant process uses a lease concept with a controllable time period. This eases the network installation procedure on the client computer side considerably.


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).
This decision remains transparent to clients.


===Information===
Some DHCP server implementations can update the DNS name associated with the client hosts to reflect the new IP address. They make use of the DNS update protocol established with RFC 2136.
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===
==Basic Server Configuration==
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==
At the top of the dhcpd.conf file is a header which contains the configuration to global parameters by the server itself, and which is applicable by each of the supported subnets, unless this header is specifically overridden. Following this header are declarations so to configure all subnets which are accessible of this server, whether those have actual DHCP services or not.
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>


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''.
Configuration is done by various statements within the dhcpd.conf file, which can be either a declaration or a parameter. A declaration describes the topology of your network : and these declarations specify what subnets are valid, and what configuration to a specific host is valid. Parameters define the various characteristics, like how to do something, what route to take, how to behave, the length of time which a lease is valid by, and other characteristics like IP addresses.


==Options==
At its simplest form, a DHCP configuration entry is a subnet address, the netmask, and the range of IP addresses. By example:
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.
subnet 10.2.0.0 netmask 255.255.0.0 {
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".
range 10.2.3.0 10.2.3.200;
}
This entry applies by the Class A network 10.2.0.0. ; but only addresses by a much smaller network as 10.2.3.0 are available : and not all the addresses within this latter range are available, because the highest address permitted here is 10.2.3.200. Each entry is followed of a semi-colon.


The following tables list the available DHCP options.{{Ref RFC|2132}}<ref name=":0" />
Hosts can be configured individually also by using the keyword as "host" by the file as dhcpd.conf, and then following this by the name of the host.
By this example, we use the hardware and fixed-address options so to define the configuration to this specific host.


{| class="wikitable sortable"
The hardware and fixed-address options have the general syntax:
|+ RFC 1497 (BOOTP Vendor Information Extensions) vendor extensions<ref name=rfc2132/>{{rp|Section 3}}
option option-name option-data
What is valid as "option-data" will depend upon the option which is occurring : and some of these options are IP addresses and hostnames ; and others can be text strings or numbers, and others are Boolean values like true/false or on/off. Note that you actually need to include the word as "option" to tell the DHCP server that what follows is an option, and not a subnet declaration or something other. If an option is specified as a global parameter, then this applies by all the subnets. Mentioned below, you can also override a global parameter which set here by the subnet definitions.

This table is a list of the more common dhcpd options : but there are dozens more, and many of those apply only by specific protocols and services like NNTP, finger, IRC, and so forth. For a complete list of options in more detail, check out the dhcp-options man-page.


{| class="wikitable"
|-
|-
! Code !! Name !! Length !! Notes
Table 1 - Common dhcpd.conf Configuration Options and Declarations
|-
|-
| 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
!|
Parameter
| Description
| Datatype
|-
|-
| 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.
!|
default-lease-time
| Default length in seconds the lease is valid
| Numeric
|-
|-
| 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.
!|
domain-name
| The name of the domain for the specified subnet
| Text
|-
|-
| 3 || Router || Multiples of 4 octets || Available routers, should be listed in order of preference
!|
domain-name-servers
| A list of name servers for the specified subnet.
| List of
| IP addresses
|-
|-
| 4 || Time server || Multiples of 4 octets || Available [[Time Protocol]] servers to synchronise with, should be listed in order of preference
!|
fixed-address
| Static addressto assign to a host
| List of
| IP addresses(supports multiple networks)
|-
|-
| 5 || Name server || Multiples of 4 octets || Available [[IEN 116]] name servers, should be listed in order of preference
!|
group
| Starts a group declaration
| N/A
|-
|-
| 6 || Domain name server || Multiples of 4 octets || Available [[DNS]] servers, should be listed in order of preference
!|
hardware
| The type of hardware the networkinterface has (currently only ethernet and toke-ring are supported)
| Hardware-type: text
|-
|-
| 7 || Log server || Multiples of 4 octets || Available log servers, should be listed in order of preference
!|
Hardware-address:
| Octets, colon separated.
| N/A
|-
!|
Host
| Starts a host declaration
| N/A
|-
|-
| 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]].
!|
host-name
| Name to assign to the requesting host
| Text
|-
|-
| 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
!|
max-lease-time
| Maximum time seconds the server will grant alease should the client request a specific lease
| Numeric time
|-
|-
| 10 || Impress server || Multiples of 4 octets ||A list of Imagen Impress servers available to the client, should be listed in order of preference
!|
netbios-name-servers
| Name of the
| WINS server
| List of
| IP addresses
|-
|-
| 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
!|
range
| Range of
| IP addresses to assign on the specified network
| Low and high
| IP address
|-
|-
| 12 || Host name || Minimum of 1 octet ||Name of the client. The name may be qualified with the local domain name.
!|
routers
| A list of routers to use
| List of
| IP addresses
|-
|-
| 13 || Boot file size || 2 octets || Length of the boot image in 512B blocks
!|
shared-network
| Starts a shared network declaration
| N/A
|-
|-
| 14 || [[Merit Network|Merit]] dump file || Minimum of 1 octet || Path where crash dumps should be stored
!|
subnet
| Starts a subnet declaration
| N/A
|-
|-
| 15 || Domain name || Minimum of 1 octet ||
!|
subnet-mask
| The subnet-mask of this network, group, host or
| IP address
|-
|-
| 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
|}
|}


{| class="wikitable sortable"
One of the specific definitions by the host is "hardware", and following the type, like "Ethernet" or "token-ring", is the physical address of the card (i.e. the MAC address). As example, you might have something like this:
|+ IP layer parameters per host<ref name=rfc2132/>{{rp|Section 4}}
host saturn {
|-
hardware ethernet 00:50:04:53:F8:D2;
! Code !! Name !! Length !! Notes
fixed-address 192.168.42.3;
|-
}
| 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 ||
|}


{| class="wikitable sortable"
This example says that the machine as saturn has an Ethernet card with the MAC address 00:50:04:53:F8:D2 and it is to be assigned the fixed address as 192.168.42.3.
|+ IP Layer Parameters per Interface<ref name=rfc2132/>{{rp|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
|}


{| class="wikitable sortable"
Sometimes you want to specify options by a number of machines at your network without having to consider those a separate subnet. By example, you could define a subnet by a group of machines, and then apply specific options by only this subnet. These special nodes cannot have IP addresses at the same subnet where the others are at : and to overcome this limitation, you can group machines together by using the keyword as "group". All options included within this definition as group, apply by a group. Like subnets, it is also to specify individual hosts within the group. By example:
|+ Link layer parameters per interface<ref name=rfc2132/>{{rp|Section 6}}
group {
|-
default-lease-time 500000;
! Code !! Name !! Length !! Notes
option routers 192.168.42.1;
|-
host jupiter {
| 34 || Trailer encapsulation option || 1 octet ||
hardware ethernet 00:50:04:53:D5:57;
|-
default-lease-time 700000;
| 35 || ARP cache timeout || 4 octets ||
}
|-
host saturn {
| 36 || Ethernet encapsulation || 1 octet ||
hardware ethernet 00:50:04:53:F8:D2;
}
|}
host uranus {
hardware ethernet 00:50:04:53:32:8F;
}
}
By this example, we set the default lease time (how long the lease is valid) by the group, 500000 seconds (more than 6 days), and the router is the machine with the IP address as 192.168.42.1. This definition applies by the three hosts listed. Although by the host as jupiter we set the default lease time into a higher value the router definition still applies.


{| class="wikitable sortable"
Another consideration is where there are many networks at the same physical network segment : there are several reasons why such a configuration may be required, and the ISC DCHP enables you to configure your system accordingly ; and this is done by declaring a shared-network. A shared network is basically nothing more than a container by a group of machines : and one difference by this from the declaration as "group" is that a shared-network declaration can contain subnets also than groups or individual hosts. The declaration as "shared network" has the general syntax:
|+ TCP parameters<ref name=rfc2132/>{{rp|Section 7}}
shared-network network-name {
|-
shared-network-specific parameters
! Code !! Name !! Length !! Notes
subnet {
|-
subnet-specific parameters
| 37 || TCP default TTL || 1 octet ||
}
|-
group {
| 38 || TCP keepalive interval || 4 octets ||
group-specific parameters
|-
}
| 39 || TCP keepalive garbage || 1 octet ||
}
|}
Note that within both the declarations by group and the declarations by subnet, you can specify parameters by individual hosts, like you can when those hosts are not part of a shared-network.


{| class="wikitable sortable"
Although the configuration to the DHCP server seems straightforward, having to administer a large number of systems by editing files can become tedious. Webmin (www.webmin.com) provides a graphical, web-based interface by a large number of system functions (including DHCP) : and the primary DHCP configuration page shows the subnets which one specific machine manages, and also shows all shared networks which are configured. Many machines may be specifically configured also than as groups of machines : and when you select each object, you can configure the same options which you can by editing files.
|+ Application and service parameters<ref name=rfc2132/>{{rp|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]] (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"
Devesh pant (planman media)
|+ DHCP extensions<ref name=rfc2132/>{{rp|Section 9}}
|-
! Code !! Name !! Length !! Notes
|-
| 50 || Requested IP address || 4 octets ||
|-
| 51 || IP address lease time || 4 octets ||
|-
| 52 || Option overload || 1 octet ||
|-
| 53 || DHCP message type || 1 octet ||
|-
| 54 || Server identifier || 4 octets ||
|-
| 55 || Parameter request list || Minimum of 1 octet ||
|-
| 56 || Message || Minimum of 1 octet ||
|-
| 57 || Maximum DHCP message size || 2 octets ||
|-
| 58 || Renewal (T1) time value || 4 octets ||
|-
| 59 || Rebinding (T2) time value || 4 octets ||
|-
| 60 || Vendor class identifier || Minimum of 1 octet ||
|-
| 61 || Client identifier || Minimum of 2 octets ||
|-
| 66 || TFTP server name || Minimum of 1 octet ||
|-
| 67 || Bootfile name || Minimum of 1 octet ||
|}


===DHCP message types===
==Troubleshooting the Server==


This table lists the DHCP message types, documented in RFC 2132, RFC 3203,<ref name="rfc3203">{{cite IETF
By complex DHCP configurations it is often difficult to understand what parameter applies by which host ; when trying to deduce what is happening, there are two important things to remember : firstly that host or group declarations can specifically override the global definition and the group declarations ; and secondly that definitions are not necessarily applied into the same order by which those appeared within the file as dhcpd.conf. The server checks whether a configuration to a specific host by the server is ordained, and then whether a configuration to a group is specified by the server, and then by the configuration to the subnet by the server, and then by the configuration to a shared-network by the server : and then the declarations by global variables by the server are assessed. Configurative options are added by and not replaced : therefore, the configuration to the smaller, more specific units (like hosts) have precedence above the configuration to more general units (like global parameters). So, when probems emerge, start at the bottom, and work your way up.
| title = DHCP reconfigure extension
| rfc = 3203
| last1 =T'joens
| first1 = Yves
| last2 = De Schrijver
| first2 = Peter
| date = December 2001
| publisher = [[IETF]]
| access-date = November 13, 2020
}}</ref> RFC 4388,<ref name="rfc4388">{{cite IETF
| title = Dynamic Host Configuration Protocol (DHCP) Leasequery
| rfc = 4388
| last1 = Woundy
| first1 = Rich
| last2 = Kinnear
| first2 = Kim
| date = February 2006
| publisher = [[IETF]]
| access-date = November 13, 2020
}}</ref> RFC 6926<ref name="rfc6926">{{cite IETF
| title = DHCPv4 Bulk Leasequery
| rfc = 6926
| last1 = Kinnear
| first1 = Kim
| last2 = Stapp
| first2 = Mark
| last3 = Rao
| first3 = D.T.V Ramakrishna
| last4 = Joshi
| first4 = Bharat
| last5 = Russell
| first5 = Neil
| last6 = Kurapati
| first6 = Pavan
| last7 = Volz
| first7 = Bernie
| date = April 2013
| publisher = [[IETF]]
| access-date = November 13, 2020
}}</ref> and RFC 7724.<ref name="rfc7724">{{cite IETF
| title = Active DHCPv4 Lease Query
| rfc = 7724
| last1 = Kinnear
| first1 = Kim
| last2 = Stapp
| first2 = Mark
| last3 = Volz
| first3 = Bernie
| last4 = Russell
| first4 = Neil
| date = December 2015
| publisher = [[IETF]]
| access-date = November 13, 2020
}}</ref> These codes are the value in the DHCP extension 53, shown in the
table above.


{| class="wikitable sortable"
Perhaps the most basic technique by troubleshooting is to look at what leases the server has assigned. This is done by looking at the leases file as /var/state/dhcp/dhcp.leases , which maintains the current state of all active leases. One thing to recognise is that this file is re-written at timely intervals after a backup is made with the name as "dhcpd.leases~" so to prevent this file becoming too large, Although rare, it can happen that by some reason the server dies at this point, at which circumstances there would be no dhcpd.leases file, and thus server would not be able to restart. Rather than creating an empty dhcpd.leases file, you would rename dhcpd.leases~ to establish things correctly.
|+ DHCP message types
|-
Within the contents of the dhcpd.leases file, each lease declaration is identified by the keyword as "lease" which is then followed by the IP address and information as configurational parameters which are contained inside of curly brackets. As example, there might be something like this:
! Code !! Name !! Length !! RFC
lease 192.168.42.1 {
|-
starts 0 2000/01/30 08:02:54;
| 1 || DHCPDISCOVER || 1 octet || rfc2132<ref name=rfc2132/>{{rp|Section 9.6}}
ends 5 2000/02/04 08:02:54;
|-
hardware ethernet 00:50:04:53:D5:57;
| 2 || DHCPOFFER || 1 octet || rfc2132<ref name=rfc2132/>{{rp|Section 9.6}}
uid 01:00:50:04:53:D5:57;
|-
client-hostname "PC0097";
| 3 || DHCPREQUEST || 1 octet || rfc2132<ref name=rfc2132/>{{rp|Section 9.6}}
}
|-
The statements as "starts" and "ends" indicate the period when the lease is valid. Each entry is of the form:
| 4 || DHCPDECLINE || 1 octet || rfc2132<ref name=rfc2132/>{{rp|Section 9.6}}
weekday yyyy/mm/dd hh:mm:ss;
|-
The weekday is the numerical value for the day of the week starting with 0 by Sunday, as by this case. The date and time are Greenwich Mean Time, and not local time.
| 5 || DHCPACK || 1 octet || rfc2132<ref name=rfc2132/>{{rp|Section 9.6}}
|-
| 6 || DHCPNAK || 1 octet || rfc2132<ref name=rfc2132/>{{rp|Section 9.6}}
|-
| 7 || DHCPRELEASE || 1 octet || rfc2132<ref name=rfc2132/>{{rp|Section 9.6}}
|-
| 8 || DHCPINFORM || 1 octet || rfc2132<ref name=rfc2132/>{{rp|Section 9.6}}
|-
| 9 || DHCPFORCERENEW || 1 octet || rfc3203<ref name=rfc3203/>{{rp|Section 4}}
|-
| 10 || DHCPLEASEQUERY || 1 octet || rfc4388<ref name=rfc4388/>{{rp|Section 6.1}}
|-
| 11 || DHCPLEASEUNASSIGNED || 1 octet || rfc4388<ref name=rfc4388/>{{rp|Section 6.1}}
|-
| 12 || DHCPLEASEUNKNOWN || 1 octet || rfc4388<ref name=rfc4388/>{{rp|Section 6.1}}
|-
| 13 || DHCPLEASEACTIVE || 1 octet || rfc4388<ref name=rfc4388/>{{rp|Section 6.1}}
|-
| 14 || DHCPBULKLEASEQUERY || 1 octet || rfc6926<ref name=rfc6926/>{{rp|Section 6.2.1}}
|-
| 15 || DHCPLEASEQUERYDONE || 1 octet || rfc6926<ref name=rfc6926/>{{rp|Section 6.2.1}}
|-
| 16 || DHCPACTIVELEASEQUERY || 1 octet || rfc7724<ref name=rfc7724/>{{rp|Section 5.2.1}}
|-
| 17 || DHCPLEASEQUERYSTATUS || 1 octet || rfc7724<ref name=rfc7724/>{{rp|Section 5.2.1}}
|-
| 18 || DHCPTLS || 1 octet || rfc7724<ref name=rfc7724/>{{rp|Section 5.2.1}}
|}


====Client vendor identification====
The hardware entry is the same as that within the dhcpd.conf file. The uid entry is uniquely identifiable by the client, and this may take the form as a number for the hardware type, which is subsequently succeeded of the hardware address. Alternatively an ASCII string may identify the client.
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.
Sometimes the client wants to specify its own name, and there are two ways a client can do this : one is by using the option as "client-hostname" ; and the other way a client may specify its own name is by using the option as "Hostname", which is used of many operating systems, like Windows 95, and the name of the host follows.


Setting a VCI by the client allows a DHCP server to differentiate between client machines and process the requests from them appropriately.
If there is a problem by the way that the client is configured then an entry within the dhcpd.leases file might not achieve desirable results. One approach by investigation would be to remove any applicable entry (based either upon the IP address or hardware address) and then re-start the server.


===Other extensions===
It may be necessary to see what the server thinks that it is doing rather than looking at the client or dhcpd.leases file and guessing what the server thinks that it is doing. To observe reality can be accomplished by running the dhcp server within the foreground (by using the -f option) and by telling it to output all its error messages by stderr (by using the -d option) instead for using the system logging daemon. You can watch the server accept and process requests.
{| class="wikitable sortable"
|+ Documented DHCP options
|-
! Code !! Name !! Length !! RFC
|-
| 77 || User Class || Minimum of 2 octets || RFC 3004<ref name="ietf_spec_dhcp77">{{cite journal|last1=Stump|first1=G.|last2=Droms|first2=R.|last3=Gu|first3=Y.|last4=Vyaghrapuri|first4=R.|last5=Demirtjis|first5=A.|last6=Beser|first6=B.|last7=Privat|first7=J.|title=The User Class Option for DHCP|url=https://tools.ietf.org/html/rfc3004|website=IETF Documents|publisher=[[IETF]]|access-date=2 April 2024|doi=10.17487/RFC3004|date=November 2000|doi-access=}}</ref>
|-
| 82 || [[#Relay agent information sub-options|Relay agent information]] || Minimum of 2 octets || RFC 3046<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=}}</ref>
|-
| 85 || [[Novell Directory Service]] (NDS) servers || Minimum of 4 octets, multiple of 4 octets || RFC 2241<ref name="ietf_spec_dhcp85-86-87">{{cite journal|last1=Provan|first1=Don|title=RFC 2241 – DHCP Options for Novell Directory Services|url=https://tools.ietf.org/html/rfc2241|website=IETF Documents|publisher=[[IETF]]|access-date=23 July 2017|doi=10.17487/RFC3256|date=November 1997|doi-access=|url-access=subscription}}</ref>{{rp|Section 2}}
|-
| 86 || NDS tree name || Variable || RFC 2241<ref name="ietf_spec_dhcp85-86-87"/>{{rp|Section 3}}
|-
| 87 || NDS context || Variable || RFC 2241<ref name="ietf_spec_dhcp85-86-87"/>{{rp|Section 4}}
|-
| 100 || [[Time zone]], POSIX style || Variable || RFC 4833<ref name="ietf_spec_dhcp100-101">{{cite journal|last1=Lear|first1=E.|last2=Eggert|first2=P.|title=Timezone Options for DHCP|url=https://tools.ietf.org/html/rfc4833|website=IETF Documents|publisher=[[IETF]]|date=April 2007|doi=10.17487/RFC4833 |access-date=28 June 2018}}</ref>
|-
| 101 || [[Time zone]], [[tz database]] style || Variable || RFC 4833<ref name="ietf_spec_dhcp100-101"/>
|-
| 114 || DHCP Captive-Portal || Variable || RFC 8910<ref>{{cite journal |last1=Kumari |first1=Warren |title=RFC 8910 - Captive-Portal Identification in DHCP and Router Advertisements (RAs) |url=https://tools.ietf.org/html/rfc8910 |website=ietf.org |date=September 2020 |publisher=IETF |access-date=25 March 2021}}</ref>
|-
| 119 || [[Search domain|Domain search]] || Variable || RFC 3397<ref name="ietf_spec_dhcp119">{{cite journal|doi=10.17487/RFC3397|last1=Bernard|first1=Aboba|last2=Stuart|first2=Cheshire|title=RFC 3397 – Dynamic Host Configuration Protocol (DHCP) Domain Search Option|url=https://tools.ietf.org/html/rfc3397|website=IETF Documents|publisher=[[IETF]]|date=November 2002|access-date=22 July 2017|doi-access=}}</ref>
|-
| 121 || Classless static route || Variable || RFC 3442<ref name="ietf_spec_dhcp121">{{cite ietf |url=https://tools.ietf.org/html/rfc3442 |title=The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) |version=v. 4 |date=December 2002 |doi=10.17487/RFC3442 |rfc=3442 |last1=Lemon |first1=T. |last2=Cheshire |first2=S. |last3=Volz |first3=B. |doi-access=free}}</ref>
|-
| 209 || Configuration File || Variable || RFC 5071<ref name="rfc5071">{{cite journal |last1=Hankins |first1=David |title=RFC 5071 - Dynamic Host Configuration Protocol Options Used by PXELINUX |url=https://tools.ietf.org/html/rfc5071 |website=ietf.org |date=December 2007 |publisher=IETF |doi=10.17487/RFC5071 |access-date=25 March 2021}}</ref>
|-
| 210 || Path Prefix || Variable || RFC 5071<ref name="rfc5071"/>
|-
| 211 || Reboot Time || Variable || RFC 5071<ref name="rfc5071"/>
|}


====Relay agent information sub-options====
==Client Configuration==
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"/>


{| class="wikitable sortable"
Configuration to the client-side is dependent upon your distribution. By example, if your operating system is SuSE 6.3, then you may go by the portion as network configuration of YAST and select the basic network configuration. If you press F3 sets auto-IP configuration, which gives you the choice as whether to configure DHCP or BOOTP, and by selecting DHCP this ought to make changes by the file as /etc/rc.config by setting the configuration to parameters of the respective card at the client side as "dhcpclient". By example, without DHCP you might have an entry like this:
|+ Relay agent sub-options
IFCONFIG_0="192.168.42.1 broadcast 192.168.42.255 netmask 255.255.255.0 up"
|-
If DHCP is configured through the above then the entry would look like this:
! Code !! Name !! Length !! RFC
IFCONFIG_0="dhcpclient"
|-
Note that you could have some of the interfaces configured so to use DHCP and others with static addresses. When the client machine boots, the /etc/rc.d/network script is called (by example, as /etc/rc.d/rc2.d/S05network), and if this machine discovers that the IFCONFIG line by the respective card is by "dhcpclient", then it will avoid configuration by its interface, until instructed further. Later at the boot process, usually the script as DHCP client is started (by example, as /etc/rc.d/rc2.d/S05dhclient), and now the client tries to receive its configuration from the DHCP server.
| 1 || Agent Circuit ID || Minimum of 1 octet || RFC 3046<ref name="ietf_spec_dhcp82"/>
|-
| 2 || Agent Remote ID || Minimum of 1 octet || RFC 3046<ref name="ietf_spec_dhcp82"/>
|-
| 4 || Data-Over-Cable Service Interface Specifications (DOCSIS) device class || 4 octets || RFC 3256<ref name="ietf_spec_riasub4">{{cite journal|last1=Doug|first1=Jones|last2=Rich|first2=Woundy|title=RFC 3256 – The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option|url=https://tools.ietf.org/html/rfc3256|website=IETF Documents|publisher=[[IETF]]|access-date=23 July 2017|doi=10.17487/RFC3256|date=April 2002|doi-access=|url-access=subscription}}</ref>
|}


==Relaying==
Upon other systems, like Caldera or Redhat, an own configuration tool changes the appropriate file within /etc/sysconfig/network-scripts/. As example, if you were configuring DHCP on your eth0 interface, the script as ifcfg-eth0 would be changed.
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.
DEVICE=eth0
IPADDR=0.0.0.0
NETMASK=255.255.255.0
NETWORK=
BROADCAST=0.0.0.255
GATEWAY=none
ONBOOT=yes
DYNAMIC=dhcp
Find the line labeled DYNAMIC= and change it to DYNAMIC=dhcp.


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.
In most cases the default configuration to the client by the server is sufficient : and if not, the client has it's own configuration file: /etc/dhclient.conf. If you have more than one interface with different network options upon your client computer, you need to group the options by interface. By example,
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.
interface eth0 {
The DHCP server uses the GIADDR-value to determine the subnet, and subsequently the corresponding address pool, from which to allocate an IP address.
send dhcp-lease-time 3600;
When the DHCP server replies to the client, it sends the reply to the GIADDR-address, again using unicast.
request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name;
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.
require subnet-mask, domain-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}}
}
Directly after processing the packet, the client sets the IP address on its interface and is ready for regular IP communication, directly thereafter.
The statement as send tells the client to send the associated option with the specified value, all the options which the server understands may be sent. These are defined into detail by the dhcp-options (5) man-page.


If the client's implementation of the IP stack does not accept unicast packets when it has no IP address yet, the client may set the ''broadcast'' bit in the FLAGS field when sending a DHCPDISCOVER packet.
The statement as request is a list of configuration options (not the values) which the client requests that the server should send by the client : and this particular configuration option must be sent of a server so that the client may believe that the server is listening.
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.
==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.


==Client states==
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:
[[File:Dhcp-client-state-diagram.svg|thumb|A simplified DHCP client state-transition diagram based on figure 5 of RFC 2131]]
* 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


A DHCP client can receive these messages from a server:{{Ref RFC|2131|rsection=4.4}}
===Example in ipfw firewall===
* DHCPOFFER
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 :
* DHCPACK
pass udp from 0.0.0.0,192.168.0.0/24 68 to me 67 in recv rl0
* DHCPNAK
pass udp from any 68 to 255.255.255.255 67 in recv rl0
pass udp from me 67 to 192.168.0.0/24,255.255.255.255 68 out xmit rl0


The client moves through DHCP states depending on how the server responds to the messages that the client sends.
===Example in Cisco IOS Extended ACL===
The following entries are valid on a Cisco 3560 switch with enabled DHCP service. The [[Access control list|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


==Reliability==
==Technical details==
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.
[[Image:DHCP_session_en.svg|thumb|Schema of a typical DHCP session]]


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.
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 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
DHCP operations fall into four basic phases. These phases are IP lease request, IP lease offer, IP lease selection, and IP lease acknowledgement.
| title = DHCP Failover Protocol
| draft = draft-ietf-dhc-failover-12
| last1 = Droms | first1 = Ralph
| last2 = Kinnear | first2 = Kim
| last3 = Stapp | first3 = Mark
| last4 = Volz | first4 = Bernie
| last5 = Gonczi | first5 = Steve
| last6 = Rabil | first6 = Greg
| last7 = Dooley | first7 = Michael
| last8 = Kapur | first8 = Arun
| date = March 2003
| publisher = [[IETF]]
| access-date = May 9, 2010
}}</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.}}


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.
After the client obtained an IP address, the client may start an [[Address Resolution Protocol|address resolution query]] to prevent IP conflicts caused by address poll overlapping of DHCP servers.


===DHCP discovery===
==IPv6 networks==
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>
The client broadcasts on the 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.


==Security==
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.
{{see also|DHCP snooping}}
The base DHCP does not include any mechanism for authentication.{{Ref RFC|3046|rsection=7}}
Because of this, it is vulnerable to a variety of attacks. These attacks fall into three main categories:{{Ref RFC|2131}}{{rp|sec. 7}}


* Unauthorized DHCP servers providing false information to clients.
<table border="0">
* Unauthorized clients gaining access to resources.
<tr><td valign="top">
* Resource exhaustion attacks from malicious DHCP clients.
<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><th colspan=4>Magic Cookie</th></tr>
<tr><td colspan=4>0x63825363</td></tr>
<tr><th colspan=4>DHCP Options</th></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>


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" />
===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.


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>


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}}


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


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>
<td valign="top"><table class="wikitable"><caption>DHCPOFFER</caption>
<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><th colspan=4>Magic Cookie</th></tr>
<tr><td colspan=4>0x63825363</td></tr>
<tr><th colspan=4>DHCP Options</th></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>


==IETF standards documents==
===DHCP requests===
* {{IETF RFC|2131|link=no}}, Dynamic Host Configuration Protocol
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.
* {{IETF RFC|2132|link=no}}, DHCP Options and BOOTP Vendor Extensions
* {{IETF RFC|3046|link=no}}, DHCP Relay Agent Information Option
* {{IETF RFC|3397|link=no}}, Dynamic Host Configuration Protocol (DHCP) Domain Search Option
* {{IETF RFC|3942|link=no}}, Reclassifying Dynamic Host Configuration Protocol Version Four (DHCPv4) Options
* {{IETF RFC|4242|link=no}}, Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6
* {{IETF RFC|4361|link=no}}, Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
* {{IETF RFC|4436|link=no}}, Detecting Network Attachment in IPv4 (DNAv4)
* {{IETF RFC|3442|link=no}}, Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4
* {{IETF RFC|3203|link=no}}, DHCP reconfigure extension
* {{IETF RFC|4388|link=no}}, Dynamic Host Configuration Protocol (DHCP) Leasequery
* {{IETF RFC|6926|link=no}}, DHCPv4 Bulk Leasequery
* {{IETF RFC|7724|link=no}}, Active DHCPv4 Lease Query


==See also==
{{cols}}
* [[Boot Service Discovery Protocol]] (BSDP){{snd}} a DHCP extension used by Apple's [[NetBoot]]
* [[Comparison of DHCP server software]]
* {{Ref RFC|2322|ref=no}}
* [[Preboot Execution Environment]] (PXE)
* [[Reverse Address Resolution Protocol]] (RARP)
* [[Rogue DHCP]]
* [[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}}


==Notes==
<td valign="top"><table class="wikitable"><caption>DHCPREQUEST</caption>
{{Notelist}}
<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><th colspan=4>Magic Cookie</th></tr>
<tr><td colspan=4>0x63825363</td></tr>
<tr><th colspan=4>DHCP Options</th></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>


==References==
===DHCP acknowledgement===
{{Reflist|30em}}
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.


== External links ==
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.


* {{commons category-inline|Dynamic Host Configuration Protocol (DHCP)}}
<td valign="top"><table class="wikitable"><caption>DHCPACK</caption>
<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 (Client IP Address)</th></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><th colspan=4>YIADDR (Your IP Address)</th></tr>
<tr><td colspan=4>0xC0A80164</td></tr>
<tr><th colspan=4>SIADDR (Server IP Address)</th></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><th colspan=4>GIADDR (Relay IP Address)</th></tr>
<tr><td colspan=4>0x00000000</td></tr>
<tr><th colspan=4>CHADDR (Client Hardware Address)</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><th colspan=4>Magic Cookie</th></tr>
<tr><td colspan=4>0x63825363</td></tr>
<tr><th colspan=4>DHCP Options</th></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>


{{Authority control}}
===DHCP information===
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.


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

===Client configuration parameters===
A DHCP server can provide optional configuration parameters to the client. RFC 2132 defines the available DHCP options, which are summarized here.
Defined by [[Internet Assigned Numbers Authority]] (IANA) - [http://www.iana.org/assignments/bootp-dhcp-parameters DHCP and BOOTP PARAMETERS] (last updated 2007-05-25)

''RFC 1497 Vendor Extensions:''
Data
Tag Name Length Meaning
--- ---- ------ -------
0 Pad Option 0 None
255 End Option 0 None
1 Subnet Mask 4 Subnet Mask Value
2 Time Offset 4 Time Offset in
Seconds from UTC
3 Router N×4 Router addresses
4 Time Server N×4 Timeserver addresses
5 Name Server N×4 IEN-116 Server addresses
6 Domain Server N×4 DNS Server addresses
7 Log Server N×4 Logging Server addresses
8 Quotes Server N×4 Quotes Server addresses
9 LPR Server N×4 Printer Server addresses
10 Impress Server N×4 Impress Server addresses
11 RLP Server N×4 N RLP Server addresses
12 Hostname N Hostname string
13 Boot File Size 2 Size of boot file in 512-octet
blocks
14 Merit Dump File N Client to dump and name
the file to dump it to
15 Domain Name N The DNS domain name of the
client
16 Swap Server 4 Swap Server address
17 Root Path N Path name for root disk
18 Extensions File N Path name for more BOOTP info

''IP Layer Parameters per Host:''

19 Forward On/Off 1 Enable/Disable IP Forwarding
20 SrcRte On/Off 1 Enable/Disable Non-Local Source Routing
21 Policy Filter N×8 Non-Local Source Routing Policy Filters
22 Max DG Assembly 2 Max Datagram Reassembly Size
23 Default IP TTL 1 Default IP Time to Live
24 MTU Timeout 4 Path MTU Aging Timeout
25 MTU Plateau N×2 Path MTU Plateau Table

''IP Layer Parameters per Interface:''

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

''Link Layer Parameters per Interface:''

34 Trailers 1 Trailer Encapsulation
35 ARP Timeout 4 ARP Cache Timeout
36 Ethernet 1 Ethernet Encapsulation

''TCP Parameters:''

37 Default TCP TTL 1 Default TCP Time to Live
38 Keepalive Time 4 TCP Keepalive Interval
39 Keepalive Data 1 TCP Keepalive Garbage

''Application and Service Parameters:''

40 NIS Domain N NIS Domain Name
41 NIS Servers N×4 NIS Server Addresses
42 NTP Servers N×4 NTP Server Addresses
43 Vendor Specific N Vendor Specific Information
44 NETBIOS Name Srv N×4 NETBIOS Name Servers
45 NETBIOS Dist Srv N×4 NETBIOS Datagram Distribution
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

''DHCP Extensions:''

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

''Newer extensions:''

62 Netware/IP Domain N Netware/IP Domain Name
63 Netware/IP Option N Netware/IP sub Options
77 User-Class N User Class Information
78 Directory Agent N directory agent information
79 Service Scope N service location agent scope
80 Rapid Commit 0 Rapid Commit
81 Client FQDN N Fully Qualified Domain Name
82 Relay Agent Information N Relay Agent Information, RFC 3046
83 iSNS N Internet Storage Name Service
84 REMOVED/Unassigned
85 NDS Servers N Novell Directory Services
86 NDS Tree Name N Novell Directory Services
87 NDS Context N Novell Directory Services
88 BCMCS Controller Domain Name list
89 BCMCS Controller IPv4 address option
90 Authentication N Authentication
91-92 REMOVED/Unassigned
93 Client System N Client System Architecture
94 Client NDI N Client Network Device Interface
95 LDAP N Lightweight Directory Access Protocol
96 REMOVED/Unassigned
97 UUID/GUID N UUID/GUID-based Client Identifier
98 User-Auth N Open Group's User Authentication
99-111 REMOVED/Unassigned
112 Netinfo Address N NetInfo Parent Server Address
113 Netinfo Tag N NetInfo Parent Server Tag
114 URL N URL
115 REMOVED/Unassigned
116 Auto-Config N DHCP Auto-Configuration
117 Name Service Search N Name Service Search
118 Subnet Selection Option 4 Subnet Selection Option
119 Domain Search N DNS domain search list
120 SIP Servers DHCP Option N SIP Servers DHCP Option
121 Classless Static Route N Classless Static Route Option
Option
122 CCC N CableLabs Client Configuration
123 GeoConf Option 16 GeoConf Option
124 V-I Vendor Class Vendor-Identifying Vendor Class
125 V-I Vendor-Specific Vendor-Identifying Vendor-Specific
Information Information
126-127 Removed/Unassigned
128 PXE - undefined (vendor specific) (Tentatively Assigned - [[23 June]] [[2005]])
128 Etherboot signature. 6 bytes: E4:45:74:68:00:00
128 DOCSIS "full security" server IP address
128 TFTP Server IP address (for IP Phone software load)
129 PXE - undefined (vendor specific) (Tentatively Assigned - [[23 June]] [[2005]])
129 Kernel options. Variable length string
129 Call Server IP address
130 PXE - undefined (vendor specific) (Tentatively Assigned - [[23 June]] [[2005]])
130 Ethernet interface. Variable length string.
130 Discrimination string (to identify vendor)
131 PXE - undefined (vendor specific) (Tentatively Assigned - [[23 June]] [[2005]])
131 Remote statistics server IP address
132 PXE - undefined (vendor specific) (Tentatively Assigned - [[23 June]] [[2005]])
132 802.1P VLAN ID
133 PXE - undefined (vendor specific) (Tentatively Assigned - [[23 June]] [[2005]])
133 802.1Q L2 Priority
134 PXE - undefined (vendor specific) (Tentatively Assigned - [[23 June]] [[2005]])
134 Diffserv Code Point
135 PXE - undefined (vendor specific) (Tentatively Assigned - [[23 June]] [[2005]])
135 HTTP Proxy for phone-specific applications
136-149 Unassigned
150 TFTP server address (Tentatively Assigned - [[23 June]] [[2005]])
150 Etherboot
150 GRUB configuration path name
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
249 Classless Static Routes (Microsoft proprietary alias for 121)
252 WPAD auto-proxy-config (Microsoft proprietary)

==See also==
*[[Bootstrap Protocol]] (BOOTP)
*[[DHCP Snooping]]
*[[Peg DHCP]] RFC 2322
*[[Preboot Execution Environment]] (PXE)
*[[Reverse Address Resolution Protocol]] (RARP)
*[[Rogue DHCP]]
*[[udhcpc]] - light version for embedded systems.
*[[Zeroconf|Zero Configuration Networking]] (Zeroconf)
*[[Web Proxy Autodiscovery Protocol]] (WPAD)

==References==
{{reflist}}

==External links==
*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 3942 - Reclassifying Dynamic Host Configuration Protocol Version Four (DHCPv4) Options
*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.
*[http://www.isc.org/index.pl?/sw/dhcp/ ISC DHCP] - Internet Services Consortium's open source DHCP implementation.
* [http://www.see-my-ip.com/tutoriales/protocolos/dhcp.php/ DHCP Tutorial]

[[Category:Internet protocols]]
[[Category:Internet standards]]
[[Category:Application layer protocols]]
[[Category:Application layer protocols]]
[[Category:Internet Standards]]

[[Category:Network service]]
[[af:DHCP]]
[[ar:بروتوكول التشكيل الدينامي]]
[[bs:Dynamic Host Configuration Protocol]]
[[bg:DHCP]]
[[ca:Dynamic Host Configuration Protocol]]
[[cs:Dynamic Host Configuration Protocol]]
[[da:DHCP]]
[[de:Dynamic Host Configuration Protocol]]
[[et:Dünaamiline hostikonfiguratsiooni protokoll]]
[[el:DHCP]]
[[es:Dynamic Host Configuration Protocol]]
[[eu:DHCP]]
[[fr:Dynamic Host Configuration Protocol]]
[[id:DHCP]]
[[it:DHCP]]
[[he:Dynamic Host Configuration Protocol]]
[[lv:DHCP]]
[[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]]
[[sr:DHCP]]
[[fi:DHCP]]
[[sv:DHCP]]
[[th:Dynamic Host Configuration Protocol]]
[[tr:DHCP]]
[[uk:DHCP]]
[[zh:DHCP]]

Latest revision as of 00:45, 14 December 2024

"DHCP" redirects here. For other uses, see DHCP (disambiguation). Not to be confused with HDCP.
Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

The Dynamic Host Configuration Protocol (DHCP) is a network management protocol used on Internet Protocol (IP) networks for automatically assigning IP addresses and other communication parameters to devices connected to the network using a client–server architecture.[1]

The technology eliminates the need for individually configuring network devices manually, and consists of two network components, a centrally installed network DHCP server and client instances of the protocol stack on each computer or device. When connected to the network, and periodically thereafter, a client requests a set of parameters from the server using DHCP.

DHCP can be implemented on networks ranging in size from residential networks to large campus networks and regional ISP networks.[2] Many routers and residential gateways have DHCP server capability. Most residential network routers receive a unique IP address within the ISP network. Within a local network, a DHCP server assigns a local IP address to each device.

DHCP services exist for networks running Internet Protocol version 4 (IPv4), as well as version 6 (IPv6). The IPv6 version of the DHCP protocol is commonly called DHCPv6.

History

[edit]

The Reverse Address Resolution Protocol (RARP) was defined in 1984 for the configuration of simple devices, such as diskless workstations, with a suitable IP address.[3] Acting in the data link layer, it made implementation difficult on many server platforms. It required that a server be present on each individual network link. RARP was superseded by the Bootstrap Protocol (BOOTP) defined in September 1985.[4] This introduced the concept of a relay agent, which allowed the forwarding of BOOTP packets across networks, allowing one central BOOTP server to serve hosts on many IP subnets.

DHCP was first defined in October 1993.[5][6] It is based on BOOTP, but can dynamically allocate IP addresses from a pool and reclaim them when they are no longer in use. It can also be used to deliver a wide range of extra configuration parameters to IP clients, including platform-specific parameters.[7]

Four years later, the DHCPINFORM message type (used for WPAD) and other small changes were added. This definition, from 1997,[8] remains the core of the standard for IPv4 networks.

DHCPv6 was initially defined in 2003.[9] After updates by many subsequent RFCs, its definition was replaced in 2018,[10] where prefix delegation and stateless address autoconfiguration were now merged.

Overview

[edit]

Internet Protocol (IP) defines how devices communicate within and across local networks on the Internet. A DHCP server can manage IP settings for devices on its local network, e.g., by assigning IP addresses to those devices automatically and dynamically.[11]

DHCP operates based on the client–server model. When a computer or other device connects to a network, the DHCP client software sends a DHCP broadcast query requesting the necessary information. Any DHCP server on the network may service the request. The DHCP server manages a pool of IP addresses and information about client configuration parameters such as default gateway, domain name, the name servers, and time servers. On receiving a DHCP request, the DHCP server may respond with specific information for each client, as previously configured by an administrator, or with a specific address and any other information valid for the entire network and for the time period for which the allocation (lease) is valid. A DHCP client typically queries this information immediately after booting, and periodically thereafter before the expiration of the information. When a DHCP client refreshes an assignment, it initially requests the same parameter values, but the DHCP server may assign a new address based on the assignment policies set by administrators.

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

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

Dynamic allocation
A network administrator reserves a range of IP addresses for DHCP, and each DHCP client on the LAN is configured to request an IP address from the DHCP server during network initialization. The request-and-grant process uses a lease concept with a controllable time period, allowing the DHCP server to reclaim and then reallocate IP addresses that are not renewed.
Automatic allocation
The DHCP server permanently assigns an IP address to a requesting client from a range defined by an administrator. This is like dynamic allocation, but the DHCP server keeps a table of past IP address assignments, so that it can preferentially assign to a client the same IP address that the client previously had.
Manual allocation
This method is also variously called static DHCP allocation, fixed address allocation, reservation, and MAC/IP address binding. An administrator maps a unique identifier (a client id or MAC address) for each client to an IP address, which is offered to the requesting client. DHCP servers may be configured to fall back to other methods if this fails.

DHCP services are used for Internet Protocol version 4 (IPv4) and IPv6. The details of the protocol for IPv4 and IPv6 differ sufficiently that they may be considered separate protocols.[12] For the IPv6 operation, devices may alternatively use stateless address autoconfiguration. IPv6 hosts may also use link-local addressing to achieve operations restricted to the local network link.

Operation

[edit]
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.[8]

The DHCP employs a connectionless service model, using the User Datagram Protocol (UDP). It is implemented with two UDP port numbers for its operations which are the same as for the bootstrap protocol (BOOTP). The server listens on UDP port number 67, and the client listens on UDP port number 68.

DHCP operations fall into four phases: server discovery, IP lease offer, IP lease request, and IP lease acknowledgement. These stages are often abbreviated as DORA for discovery, offer, request, and acknowledgement.

The DHCP operation begins with clients broadcasting a request. If the client and server are in different Broadcast Domains, a DHCP Helper or DHCP Relay Agent may be used. Clients requesting renewal of an existing lease may communicate directly via UDP unicast, since the client already has an established IP address at that point. Additionally, there is a BROADCAST flag (1 bit in 2 byte flags field, where all other bits are reserved and so are set to 0) the client can use to indicate in which way (broadcast or unicast) it can receive the DHCPOFFER: 0x8000 for broadcast, 0x0000 for unicast.[8] Usually, the DHCPOFFER is sent through unicast. For those hosts which cannot accept unicast packets before IP addresses are configured, this flag can be used to work around this issue.

Discovery

[edit]

The DHCP client broadcasts a DHCPDISCOVER message on the network subnet using the destination address 255.255.255.255 (limited broadcast) or the specific subnet broadcast address (directed broadcast). A DHCP client may also request an IP address in the DHCPDISCOVER, which the server may take into account when selecting an address to offer.

For example, if HTYPE is set to 1, to specify that the medium used is Ethernet, HLEN is set to 6 because an Ethernet address (MAC address) is 6 octets long. The CHADDR is set to the MAC address used by the client. Some options are set as well.

Example Ethernet frame with a DHCPDISCOVER message
Offset Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Source MAC (00:05:3C:04:8D:59)
4 32    
8 64 Destination MAC (FF:FF:FF:FF:FF:FF)
12 96 EtherType (0x0800)  
16 128 IPv4 packet, containing a UDP PDU with DHCP payload...
20 160
⋮ ⋮
⋮ ⋮ Frame Check Sequence
IPv4 Header
Offset Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 IPv4 header start
4 32
8 64 TTL Protocol (17 UDP) Header Checksum
UDP Header
12 96 Source Address (0.0.0.0)
16 128 Destination Address
20 160 Source Port (68) Destination Port (67)
24 192 Length Checksum
DHCP Payload: DHCPDISCOVER
28 224 OP (0x01) HTYPE (0x01) HLEN (0x06) HOPS (0x00)
32 256 XID (0x3903F326)
36 288 SECS (0x0000) FLAGS (0x0000)
40 320 CIADDR (Client IP address: 0x00000000)
44 352 YIADDR (Your IP address: 0x00000000
48 384 SIADDR (Server IP address: 0x00000000)
52 416 GIADDR (Gateway IP address: 0x00000000)
56 448 CHADDR (Client Hardware address: 0x00053C04
0x8D590000
0x00000000
0x00000000)
60 480
64 512
68 544
72 576 192 octets of 0s, or overflow space for additional options; BOOTP legacy.
⋮ ⋮
260 2080
264 2112 Magic Cookie (0x63825363)
DHCP Options (in TLV format)
292 2336 First option: 0x350101: Option 53 (DHCP Message Type) 1 octet (containing DHCPDISCOVER) Second option:↴
324 2592 ↪0x3204c0a80164: Option 50 (Request IP address) 4 octets (containing 192.168.1.100)
356 2848 Third option: 0x370401030f06: Option: 55 (Parameter Request List) 4 octets↴
388 3104 ↪PRL cont... ff

Offer

[edit]

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.[8]: §4.2 

The DHCP server determines the configuration based on the client's hardware address as specified in the CHADDR (client hardware address) field. In the following example the server (192.168.1.1) specifies the client's IP address in the YIADDR (your IP address) field.

Example Ethernet frame with a DHCPOFFER message
Offset Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Source MAC (B4:0C:25:E3:7D:62)
4 32    
8 64 Destination MAC (00:05:3C:04:8D:59)
12 96 EtherType (0x0800)  
16 128 IPv4 packet, containing a UDP PDU with DHCP payload...
20 160
⋮ ⋮
⋮ ⋮ Frame Check Sequence
IPv4 Header
Offset Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 IPv4 header start
4 32
8 64 TTL Protocol (17 UDP) Header Checksum
UDP Header
12 96 Source Address (192.168.1.1)
16 128 Destination Address (192.168.1.100)
20 160 Source Port (67) Destination Port (68)
24 192 Length Checksum
DHCP Payload: DHCPOFFER
28 224 OP (0x02) HTYPE (0x01) HLEN (0x06) HOPS (0x00)
32 256 XID (0x3903F326)
36 288 SECS (0x0000) FLAGS (0x0000)
40 320 CIADDR (Client IP address: 0x00000000)
44 352 YIADDR (Your IP address: 0xC0A80164 or 192.168.1.100)
48 384 SIADDR (Server IP address: 0xC0A80101 or 192.168.1.1)
52 416 GIADDR (Gateway IP address: 0x00000000)
56 448 CHADDR (Client Hardware address: 0x00053C04
0x8D590000
0x00000000
0x00000000)
60 480
64 512
68 544
72 576 192 octets of 0s, or overflow space for additional options; BOOTP legacy.
⋮ ⋮
260 2080
264 2112 Magic Cookie (0x63825363)
DHCP Options (in TLV format)
292 2336 First option: 0x350102: Option 53 (DHCP Message Type) 1 octet (containing DHCPOFFER) Second option:↴
324 2592 ↪0x0104ffffff00: Option 1 (Subnet mask) 4 octets (containing 255.255.255.0)
356 2848 Third option: 0x0304c0A80101: Option: 3 (Router) 4 octets (containing 192.168.1.1)↴
388 3104 ↪Router cont... Fourth option: 0x330400015080: Option 51 (Address time) 4 octets (a 86400 second lease time)↴
420 3360 ↪Address time cont... Fifth option:
452 3616 0x060c09070a0f09070a1009070a13:
Option 6 (Domain Server) 14 octets (containing 9.7.10.15,9.7.10.16,9.7.10.18)
456 3648
460 3680
482 3856   ff

Request

[edit]

In response to the DHCP offer, the client replies with a DHCPREQUEST message, broadcast to the server,[a] requesting the offered address. A client can receive DHCP offers from multiple servers, but it will accept only one DHCP offer.

The client must send the server identification option in the DHCPREQUEST message, indicating the server whose offer the client has selected.[8]: Section 3.1, Item 3  When other DHCP servers receive this message, they withdraw any offers that they have made to the client and return their offered IP address to the pool of available addresses.

Example Ethernet frame with a DHCPREQUEST message
Offset Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Source MAC (00:05:3C:04:8D:59)
4 32    
8 64 Destination MAC (FF:FF:FF:FF:FF:FF)
12 96 EtherType (0x0800)  
16 128 IPv4 packet, containing a UDP PDU with DHCP payload...
20 160
⋮ ⋮
⋮ ⋮ Frame Check Sequence
IPv4 Header
Offset Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 IPv4 header start
4 32
8 64 TTL Protocol (17 UDP) Header Checksum
UDP Header
12 96 Source Address (0.0.0.0)
16 128 Destination Address (255.255.255.255)
20 160 Source Port (68) Destination Port (67)
24 192 Length Checksum
DHCP Payload: DHCPREQUEST
28 224 OP (0x01) HTYPE (0x01) HLEN (0x06) HOPS (0x00)
32 256 XID (0x3903F326)
36 288 SECS (0x0000) FLAGS (0x0000)
40 320 CIADDR (Client IP address: 0x00000000)
44 352 YIADDR (Your IP address: 0x00000000)
48 384 SIADDR (Server IP address: 0xc0a80101 or 192.168.1.1)
52 416 GIADDR (Gateway IP address: 0x00000000)
56 448 CHADDR (Client Hardware address: 0x00053C04
0x8D590000
0x00000000
0x00000000)
60 480
64 512
68 544
72 576 192 octets of 0s, or overflow space for additional options; BOOTP legacy.
⋮ ⋮
260 2080
264 2112 Magic Cookie (0x63825363)
DHCP Options (in TLV format)
292 2336 First option: 0x350103: Option 53 (DHCP Message Type) 1 octet (containing DHCPREQUEST) Second option:↴
324 2592 ↪0x3204c0a80164: Option 50 (Request IP address) 4 octets (containing 192.168.1.100)
356 2848 Third option: 0x3604c0a801601: Option: 54 (DHCP Server) 4 octets (containing 192.168.1.1)↴
388 3104 ↪DHCP Server cont... ff

Acknowledgement

[edit]

When the DHCP server receives the DHCPREQUEST message from the client, the configuration process enters its final phase. The acknowledgement phase involves sending a DHCPACK packet to the client. This packet includes the lease duration and any other configuration information that the client might have requested. At this point, the IP configuration process is completed.

The protocol expects the DHCP client to configure its network interface with the negotiated parameters.

Example Ethernet frame with a DHCPACK message
Offset Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Source MAC (B4:0C:25:E3:7D:62)
4 32    
8 64 Destination MAC (00:05:3C:04:8D:59)
12 96 EtherType (0x0800)  
16 128 IPv4 packet, containing a UDP PDU with DHCP payload...
20 160
⋮ ⋮
⋮ ⋮ Frame Check Sequence
IPv4 Header
Offset Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 IPv4 header start
4 32
8 64 TTL Protocol (17 UDP) Header Checksum
UDP Header
12 96 Source Address (192.168.1.1)
16 128 Destination Address (192.168.1.100)
20 160 Source Port (67) Destination Port (68)
24 192 Length Checksum
DHCP Payload: DHCPACK
28 224 OP (0x02) HTYPE (0x01) HLEN (0x06) HOPS (0x00)
32 256 XID (0x3903F326)
36 288 SECS (0x0000) FLAGS (0x0000)
40 320 CIADDR (Client IP address: 0x00000000)
44 352 YIADDR (Your IP address: 0xC0A80164 or 192.168.1.100)
48 384 SIADDR (Server IP address: 0xC0A80101 or 192.168.1.1)
52 416 GIADDR (Gateway IP address: 0x00000000)
56 448 CHADDR (Client Hardware address: 0x00053C04
0x8D590000
0x00000000
0x00000000)
60 480
64 512
68 544
72 576 192 octets of 0s, or overflow space for additional options; BOOTP legacy.
⋮ ⋮
260 2080
264 2112 Magic Cookie (0x63825363)
DHCP Options (in TLV format)
292 2336 First option: 0x350105: Option 53 (DHCP Message Type) 1 octet (containing DHCPACK) Second option:↴
324 2592 ↪0x0104ffffff00: Option 1 (Subnet mask) 4 octets (containing 255.255.255.0)
356 2848 Third option: 0x0304c0A80101: Option: 3 (Router) 4 octets (containing 192.168.1.1)↴
388 3104 ↪Router cont... Fourth option: 0x330400015080: Option 51 (Address time) 4 octets (a 86400 second lease time)↴
420 3360 ↪Address time cont... Fifth option:
452 3616 0x060c09070a0f09070a1009070a13:
Option 6 (Domain Server) 14 octets (containing 9.7.10.15,9.7.10.16,9.7.10.18)
456 3648
460 3680
482 3856   ff

Selecting and configuring IP addresses

[edit]

When the server is reusing an IP address from its pool, it may first check (using ping) to see if it is not taken already.[8]: sec. 2.2  This may happen if a host is configured manually with an IP address that lies within the DHCP scope.

Before claiming an IP address, the client should probe the newly received address (e.g. with ARP), in order to find if there is another host present in the network with the proposed IP address.[8]: sec. 2.2  If there is no reply, this address does not conflict with that of another host, so it is free to be used. If this probe finds another computer using that address, the client should broadcast a DHCPDECLINE to the DHCP server(s).

Information

[edit]

A DHCP client may request more information than the server sent with the original DHCPOFFER. The client may also request repeat data for a particular application. For example, browsers use DHCP Inform to obtain web proxy settings via WPAD.

Releasing

[edit]

The client sends a request to the DHCP server to release the DHCP information and the client deactivates its IP address. As client devices usually do not know when users may unplug them from the network, the protocol does not mandate the sending of DHCP Release.

Client configuration parameters

[edit]

A DHCP server can provide optional configuration parameters to the client. RFC 2132 describes the available DHCP options defined by Internet Assigned Numbers Authority (IANA) - DHCP and BOOTP PARAMETERS.[13]

A DHCP client can select, manipulate and overwrite parameters provided by a DHCP server. In Unix-like systems this client-level refinement typically takes place according to the values in the configuration file /etc/dhclient.conf.

Options

[edit]

Options are octet strings of varying length. This is called Type–length–value encoding. The first octet is the option code, the second octet is the number of following octets and the remaining octets are code dependent. For example, the DHCP message-type option for an offer would appear as 0x35, 0x01, 0x02, where 0x35 is code 53 for "DHCP message type", 0x01 means one octet follows and 0x02 is the value of "offer".

The following tables list the available DHCP options.[14][13]

RFC 1497 (BOOTP Vendor Information Extensions) vendor extensions[14]: Section 3 
Code Name Length Notes
0 Pad 0 octets Can be used to pad other options so that they are aligned to the word boundary; is not followed by length byte
1 Subnet mask 4 octets Client's subnet mask as per RFC 950. If both the subnet mask and the router option (option 3) are included, the subnet mask option must be first.
2 Time offset 4 octets Offset of the client's subnet in seconds from Coordinated Universal Time (UTC). The offset is expressed as a two's complement 32-bit integer. A positive offset indicates a location east of the zero meridian and a negative offset indicates a location west of the zero meridian.
3 Router Multiples of 4 octets Available routers, should be listed in order of preference
4 Time server Multiples of 4 octets Available Time Protocol servers to synchronise with, should be listed in order of preference
5 Name server Multiples of 4 octets Available IEN 116 name servers, should be listed in order of preference
6 Domain name server Multiples of 4 octets Available DNS servers, should be listed in order of preference
7 Log server Multiples of 4 octets Available log servers, should be listed in order of preference
8 Cookie server Multiples of 4 octets Cookie in this case means "fortune cookie" or "quote of the day", a pithy or humorous anecdote often sent as part of a logon process on large computers; it has nothing to do with cookies sent by websites.
9 LPR Server Multiples of 4 octets A list of Line Printer Daemon protocol servers available to the client, should be listed in order of preference
10 Impress server Multiples of 4 octets A list of Imagen Impress servers available to the client, should be listed in order of preference
11 Resource location server Multiples of 4 octets A list of Resource Location Protocol servers available to the client, should be listed in order of preference
12 Host name Minimum of 1 octet Name of the client. The name may be qualified with the local domain name.
13 Boot file size 2 octets Length of the boot image in 512B blocks
14 Merit dump file Minimum of 1 octet Path where crash dumps should be stored
15 Domain name Minimum of 1 octet
16 Swap server 4 octets
17 Root path Minimum of 1 octet
18 Extensions path Minimum of 1 octet
255 End 0 octets Used to mark the end of the vendor option field
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
TCP parameters[14]: Section 7 
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 (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
DHCP extensions[14]: Section 9 
Code Name Length Notes
50 Requested IP address 4 octets
51 IP address lease time 4 octets
52 Option overload 1 octet
53 DHCP message type 1 octet
54 Server identifier 4 octets
55 Parameter request list Minimum of 1 octet
56 Message Minimum of 1 octet
57 Maximum DHCP message size 2 octets
58 Renewal (T1) time value 4 octets
59 Rebinding (T2) time value 4 octets
60 Vendor class identifier Minimum of 1 octet
61 Client identifier Minimum of 2 octets
66 TFTP server name Minimum of 1 octet
67 Bootfile name Minimum of 1 octet

DHCP message types

[edit]

This table lists the DHCP message types, documented in RFC 2132, RFC 3203,[15] RFC 4388,[16] RFC 6926[17] and RFC 7724.[18] These codes are the value in the DHCP extension 53, shown in the table above.

DHCP message types
Code Name Length RFC
1 DHCPDISCOVER 1 octet rfc2132[14]: Section 9.6 
2 DHCPOFFER 1 octet rfc2132[14]: Section 9.6 
3 DHCPREQUEST 1 octet rfc2132[14]: Section 9.6 
4 DHCPDECLINE 1 octet rfc2132[14]: Section 9.6 
5 DHCPACK 1 octet rfc2132[14]: Section 9.6 
6 DHCPNAK 1 octet rfc2132[14]: Section 9.6 
7 DHCPRELEASE 1 octet rfc2132[14]: Section 9.6 
8 DHCPINFORM 1 octet rfc2132[14]: Section 9.6 
9 DHCPFORCERENEW 1 octet rfc3203[15]: Section 4 
10 DHCPLEASEQUERY 1 octet rfc4388[16]: Section 6.1 
11 DHCPLEASEUNASSIGNED 1 octet rfc4388[16]: Section 6.1 
12 DHCPLEASEUNKNOWN 1 octet rfc4388[16]: Section 6.1 
13 DHCPLEASEACTIVE 1 octet rfc4388[16]: Section 6.1 
14 DHCPBULKLEASEQUERY 1 octet rfc6926[17]: Section 6.2.1 
15 DHCPLEASEQUERYDONE 1 octet rfc6926[17]: Section 6.2.1 
16 DHCPACTIVELEASEQUERY 1 octet rfc7724[18]: Section 5.2.1 
17 DHCPLEASEQUERYSTATUS 1 octet rfc7724[18]: Section 5.2.1 
18 DHCPTLS 1 octet rfc7724[18]: Section 5.2.1 

Client vendor identification

[edit]

An option exists to identify the vendor and functionality of a DHCP client. The information is a variable-length string of characters or octets which has a meaning specified by the vendor of the DHCP client. One method by which a DHCP client can communicate to the server that it is using a certain type of hardware or firmware is to set a value in its DHCP requests called the Vendor Class Identifier (VCI) (Option 60).

The value to which this option is set gives the DHCP server a hint about any required extra information that this client needs in a DHCP response. Some types of set-top boxes set the VCI to inform the DHCP server about the hardware type and functionality of the device. An Aruba campus wireless access point, for example, supplies value 'ArubaAP' as option 60 in its DHCPDISCOVER message.[19] The DHCP server can then augment its DHCPOFFER with an IP address of an Aruba wireless controller in option 43, so the access point knows where to register itself.

Setting a VCI by the client allows a DHCP server to differentiate between client machines and process the requests from them appropriately.

Other extensions

[edit]
Documented DHCP options
Code Name Length RFC
77 User Class Minimum of 2 octets RFC 3004[20]
82 Relay agent information Minimum of 2 octets RFC 3046[21]
85 Novell Directory Service (NDS) servers Minimum of 4 octets, multiple of 4 octets RFC 2241[22]: Section 2 
86 NDS tree name Variable RFC 2241[22]: Section 3 
87 NDS context Variable RFC 2241[22]: Section 4 
100 Time zone, POSIX style Variable RFC 4833[23]
101 Time zone, tz database style Variable RFC 4833[23]
114 DHCP Captive-Portal Variable RFC 8910[24]
119 Domain search Variable RFC 3397[25]
121 Classless static route Variable RFC 3442[26]
209 Configuration File Variable RFC 5071[27]
210 Path Prefix Variable RFC 5071[27]
211 Reboot Time Variable RFC 5071[27]

Relay agent information sub-options

[edit]

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

Relay agent sub-options
Code Name Length RFC
1 Agent Circuit ID Minimum of 1 octet RFC 3046[21]
2 Agent Remote ID Minimum of 1 octet RFC 3046[21]
4 Data-Over-Cable Service Interface Specifications (DOCSIS) device class 4 octets RFC 3256[28]

Relaying

[edit]

In small networks, where only one IP subnet is being managed, DHCP clients communicate directly with DHCP servers. However, DHCP servers can also provide IP addresses for multiple subnets. In this case, a DHCP client that has not yet acquired an IP address cannot communicate directly with a DHCP server not on the same subnet, as the client's broadcast can only be received on its own subnet.

In order to allow DHCP clients on subnets not directly served by DHCP servers to communicate with DHCP servers, DHCP relay agents can be installed on these subnets. A DHCP relay agent runs on a network device, capable of routing between the client's subnet and the subnet of the DHCP server. The DHCP client broadcasts on the local link; the relay agent receives the broadcast and transmits it to one or more DHCP servers using unicast. The IP addresses of the DHCP servers are manually configured in the relay agent. The relay agent stores its own IP address, from the interface on which it has received the client's broadcast, in the GIADDR field of the DHCP packet. The DHCP server uses the GIADDR-value to determine the subnet, and subsequently the corresponding address pool, from which to allocate an IP address. When the DHCP server replies to the client, it sends the reply to the GIADDR-address, again using unicast. The relay agent then retransmits the response on the local network, using unicast (in most cases) to the newly reserved IP address, in an Ethernet frame directed to the client's MAC address. The client should accept the packet as its own, even when that IP address is not yet set on the interface.[8]: 25  Directly after processing the packet, the client sets the IP address on its interface and is ready for regular IP communication, directly thereafter.

If the client's implementation of the IP stack does not accept unicast packets when it has no IP address yet, the client may set the broadcast bit in the FLAGS field when sending a DHCPDISCOVER packet. The relay agent will use the 255.255.255.255 broadcast IP address (and the clients MAC address) to inform the client of the server's DHCPOFFER.

The communication between the relay agent and the DHCP server typically uses both a source and destination UDP port of 67.

Client states

[edit]
A simplified DHCP client state-transition diagram based on figure 5 of RFC 2131

A DHCP client can receive these messages from a server:[8]: §4.4 

  • DHCPOFFER
  • DHCPACK
  • DHCPNAK

The client moves through DHCP states depending on how the server responds to the messages that the client sends.

Reliability

[edit]

The DHCP ensures reliability in several ways: periodic renewal, rebinding,[8]: §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.[8]: §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,[8]: §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,[8]: §4.4.5 Paragraph 5  the DHCP client will attempt to rebind, by broadcasting its DHCPREQUEST rather than unicasting it. Because it is broadcast, the DHCPREQUEST message will reach all available DHCP servers. If some other DHCP server is able to renew the lease, it will do so at this time.

In order for rebinding to work, when the client successfully contacts a backup DHCP server, that server must have accurate information about the client's binding. Maintaining accurate binding information between two servers is a complicated problem; if both servers are able to update the same lease database, there must be a mechanism to avoid conflicts between updates on the independent servers. A proposal for implementing fault-tolerant DHCP servers was submitted to the Internet Engineering Task Force, but never formalized.[29][c]

If rebinding fails, the lease will eventually expire. When the lease expires, the client must stop using the IP address granted to it in its lease.[8]: §4.4.5 Paragraph 9  At that time it will restart the DHCP process from the beginning by broadcasting a DHCPDISCOVER message. Since its lease has expired, it will accept any IP address offered to it. Once it has a new IP address (presumably from a different DHCP server) it will once again be able to use the network. However, since its IP address has changed, any ongoing connections will be broken.

IPv6 networks

[edit]

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

Security

[edit]
See also: DHCP snooping

The base DHCP does not include any mechanism for authentication.[31]: §7  Because of this, it is vulnerable to a variety of attacks. These attacks fall into three main categories:[8]: sec. 7 

  • Unauthorized DHCP servers providing false information to clients.
  • Unauthorized clients gaining access to resources.
  • Resource exhaustion attacks from malicious DHCP clients.

Because the client has no way to validate the identity of a DHCP server, unauthorized DHCP servers (commonly called "rogue DHCP") can be operated on networks, providing incorrect information to DHCP clients.[32] This can serve either as a denial-of-service attack, preventing the client from gaining access to network connectivity,[33] or as a man-in-the-middle attack.[34] Because the DHCP server provides the DHCP client with server IP addresses, such as the IP address of one or more DNS servers,[8]: 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.[35] 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.[35]

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

DHCP does provide some mechanisms for mitigating these problems. The Relay Agent Information Option protocol extension[31] (usually referred to in the industry by its actual number as Option 82[36][37]) 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.[31]: sec. 7 

Another extension, Authentication for DHCP Messages[38] (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.[39] A 2007 book about DSL technologies remarked that:

[T]here were numerous security vulnerabilities identified against the security measures proposed by RFC 3118. This fact, combined with the introduction of 802.1X, slowed the deployment and take-rate of authenticated DHCP, and it has never been widely deployed.[40]

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

Architectural proposals from 2008 involve authenticating DHCP requests using 802.1X or PANA (both of which transport EAP).[42] An IETF proposal was made for including EAP in DHCP itself, the so-called EAPoDHCP;[43] this does not appear to have progressed beyond IETF draft level, the last of which dates to 2010.[44]

IETF standards documents

[edit]
  • RFC 2131, Dynamic Host Configuration Protocol
  • RFC 2132, DHCP Options and BOOTP Vendor Extensions
  • RFC 3046, DHCP Relay Agent Information Option
  • RFC 3397, Dynamic Host Configuration Protocol (DHCP) Domain Search Option
  • RFC 3942, Reclassifying Dynamic Host Configuration Protocol Version Four (DHCPv4) Options
  • RFC 4242, Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6
  • RFC 4361, Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
  • RFC 4436, Detecting Network Attachment in IPv4 (DNAv4)
  • RFC 3442, Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4
  • RFC 3203, DHCP reconfigure extension
  • RFC 4388, Dynamic Host Configuration Protocol (DHCP) Leasequery
  • RFC 6926, DHCPv4 Bulk Leasequery
  • RFC 7724, Active DHCPv4 Lease Query

See also

[edit]

Notes

[edit]
  1. ^ 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.[8]
  2. ^ The RFC calls for the client to wait one half of the remaining time until T2 before it retransmits the DHCPREQUEST packet
  3. ^ The proposal provided a mechanism whereby two servers could remain loosely in sync with each other in such a way that even in the event of a total failure of one server, the other server could recover the lease database and continue operating. Due to the length and complexity of the specification, it was never published as a standard; however, the techniques described in the proposal are in wide use, with open-source and several commercial implementations.

References

[edit]
  1. ^ Gillis, Alexander S. "What is DHCP (Dynamic Host Configuration Protocol)?". TechTarget: SearchNetworking. Retrieved 19 February 2021.
  2. ^ Peterson, Larry L.; Davie, Bruce S. (2011). Computer Networks: A Systems Approach (5th ed.). Elsevier. ISBN 978-0-12-385060-7. Retrieved March 21, 2019.
  3. ^ R. Finlayson; T. Mann; J. Mogul; M. Theimer (June 1984). A Reverse Address Resolution Protocol. Network Working Group. doi:10.17487/RFC0903. STD 38. RFC 903. Internet Standard 38.
  4. ^ Bill Croft; John Gilmore (September 1985). BOOTSTRAP PROTOCOL (BOOTP). Network Working Group. doi:10.17487/RFC0951. RFC 951. Draft Standard. Updated by RFC 1395, 1497, 1532, 1542 and 5494.
  5. ^ R. Droms (October 1993). Dynamic Host Configuration Protocol. Network Working Group. doi:10.17487/RFC1531. RFC 1531. Obsolete. Obsoleted by RFC 1541, due to errors in the editorial process.
  6. ^ R. Droms (October 1993). Dynamic Host Configuration Protocol. Network Working Group. doi:10.17487/RFC1541. RFC 1541. Obsolete. Obsoleted by RFC 2131. Obsoletes RFC 1531.
  7. ^ Network+ Certification 2006 Published By Microsoft Press.
  8. ^ a b c d e f g h i j k l m n o p q R. Droms (March 1997). Dynamic Host Configuration Protocol. Network Working Group. doi:10.17487/RFC2131. RFC 2131. Draft Standard. Obsoletes RFC 1541. Updated by RFC 3396, 4361, 5494 and 6842.
  9. ^ J. Bound; B. Volz; T. Lemon; C. Perkins; M. Carney (July 2002). R. Droms (ed.). Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Network Working Group. doi:10.17487/RFC3315. RFC 3315. Obsolete. Obsoleted by RFC 8415. Updated by RFC 4361, 5494, 6221, 6422, 6644, 7083, 7283, 7227 and 7550.
  10. ^ T. Mrugalski; M. Siodelski; B. Volz; A. Yourtchenko; M. Richardson; S. Jiang; T. Lemon; T. Winters (November 2018). Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Internet Engineering Task Force. doi:10.17487/RFC8415. ISSN 2070-1721. RFC 8415. Proposed Standard. Obsoletes RFC 3315, 3633, 3736, 4242, 7083, 7283 and 7550.
  11. ^ "DHCP - Dynamic Host Configuration Protocol".
  12. ^ Droms, Ralph; Lemon, Ted (2003). The DHCP Handbook. SAMS Publishing. p. 436. ISBN 978-0-672-32327-0.
  13. ^ a b "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters". iana.org. Retrieved 2018-10-16.
  14. ^ a b c d e f g h i j k l m n o p S. Alexander; R. Droms (March 1997). DHCP Options and BOOTP Vendor Extensions. Network Working Group. doi:10.17487/RFC2132. RFC 2132. Draft Standard. Obsoletes RFC 1533. Updated by RFC 3442, 3942, 4361, 4833 and 5494.
  15. ^ a b T'joens, Yves; De Schrijver, Peter (December 2001). DHCP reconfigure extension. IETF. doi:10.17487/RFC3203. RFC 3203. Retrieved November 13, 2020.
  16. ^ a b c d e Woundy, Rich; Kinnear, Kim (February 2006). Dynamic Host Configuration Protocol (DHCP) Leasequery. IETF. doi:10.17487/RFC4388. RFC 4388. Retrieved November 13, 2020.
  17. ^ a b c Kinnear, Kim; Stapp, Mark; Rao, D.T.V Ramakrishna; Joshi, Bharat; Russell, Neil; Kurapati, Pavan; Volz, Bernie (April 2013). DHCPv4 Bulk Leasequery. IETF. doi:10.17487/RFC6926. RFC 6926. Retrieved November 13, 2020.
  18. ^ a b c d Kinnear, Kim; Stapp, Mark; Volz, Bernie; Russell, Neil (December 2015). Active DHCPv4 Lease Query. IETF. doi:10.17487/RFC7724. RFC 7724. Retrieved November 13, 2020.
  19. ^ "Aruba DHCP Option 60". 7 October 2020.
  20. ^ Stump, G.; Droms, R.; Gu, Y.; Vyaghrapuri, R.; Demirtjis, A.; Beser, B.; Privat, J. (November 2000). "The User Class Option for DHCP". IETF Documents. IETF. doi:10.17487/RFC3004. Retrieved 2 April 2024.
  21. ^ a b c d Patrick, Michael (January 2001). "DHCP Relay Agent Information Option". IETF Documents. IETF. doi:10.17487/RFC3046. Retrieved 22 July 2017.
  22. ^ a b c Provan, Don (November 1997). "RFC 2241 – DHCP Options for Novell Directory Services". IETF Documents. IETF. doi:10.17487/RFC3256. Retrieved 23 July 2017.
  23. ^ a b Lear, E.; Eggert, P. (April 2007). "Timezone Options for DHCP". IETF Documents. IETF. doi:10.17487/RFC4833. Retrieved 28 June 2018.
  24. ^ Kumari, Warren (September 2020). "RFC 8910 - Captive-Portal Identification in DHCP and Router Advertisements (RAs)". ietf.org. IETF. Retrieved 25 March 2021.
  25. ^ Bernard, Aboba; Stuart, Cheshire (November 2002). "RFC 3397 – Dynamic Host Configuration Protocol (DHCP) Domain Search Option". IETF Documents. IETF. doi:10.17487/RFC3397. Retrieved 22 July 2017.
  26. ^ Lemon, T.; Cheshire, S.; Volz, B. (December 2002). The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP). v. 4. doi:10.17487/RFC3442. RFC 3442.
  27. ^ a b c Hankins, David (December 2007). "RFC 5071 - Dynamic Host Configuration Protocol Options Used by PXELINUX". ietf.org. IETF. doi:10.17487/RFC5071. Retrieved 25 March 2021.
  28. ^ Doug, Jones; Rich, Woundy (April 2002). "RFC 3256 – The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option". IETF Documents. IETF. doi:10.17487/RFC3256. Retrieved 23 July 2017.
  29. ^ Droms, Ralph; Kinnear, Kim; Stapp, Mark; Volz, Bernie; Gonczi, Steve; Rabil, Greg; Dooley, Michael; Kapur, Arun (March 2003). DHCP Failover Protocol. IETF. I-D draft-ietf-dhc-failover-12. Retrieved May 9, 2010.
  30. ^ Weinberg, Neal (2018-08-14). "Why DHCP's days might be numbered". Network World. Retrieved 2019-08-07.
  31. ^ a b c M. Patrick (January 2001). DHCP Relay Agent Information Option. Network Working Group. doi:10.17487/RFC3046. RFC 3046. Proposed Standard. Updated by RFC 6607.
  32. ^ a b c Stapko, Timothy (2011). Practical Embedded Security: Building Secure Resource-Constrained Systems. Newnes. p. 39. ISBN 978-0-08-055131-9.
  33. ^ Rountree, Derrick (2013). Windows 2012 Server Network Security: Securing Your Windows Network Systems and Infrastructure. Newnes. p. 22. ISBN 978-1-59749-965-1.
  34. ^ Rooney, Timothy (2010). Introduction to IP Address Management. John Wiley & Sons. p. 180. ISBN 978-1-118-07380-3.
  35. ^ a b Golovanov (Kaspersky Labs), Sergey (June 2011). "TDSS loader now got "legs"". Archived from the original on 25 January 2021.
  36. ^ Hens, Francisco J.; Caballero, José M. (2008). Triple Play: Building the converged network for IP, VoIP and IPTV. John Wiley & Sons. p. 239. ISBN 978-0-470-75439-9.
  37. ^ Ramirez, David H. (2008). IPTV Security: Protecting High-Value Digital Contents. John Wiley & Sons. p. 55. ISBN 978-0-470-72719-5.
  38. ^ R. Droms; W. Arbaugh, eds. (June 2001). Authentication for DHCP Messages. Network Working Group. doi:10.17487/RFC3118. RFC 3118. Proposed Standard.
  39. ^ Lemon, Ted (April 2002). "Implementation of RFC 3118".
  40. ^ Golden, Philip; Dedieu, Hervé; Jacobsen, Krista S. (2007). Implementation and Applications of DSL Technology. Taylor & Francis. p. 484. ISBN 978-1-4200-1307-8.
  41. ^ Rooney, Timothy (2010). Introduction to IP Address Management. John Wiley & Sons. pp. 181–182. ISBN 978-1-118-07380-3.
  42. ^ Copeland, Rebecca (2008). Converging NGN Wireline and Mobile 3G Networks with IMS. Taylor & Francis. pp. 142–143. ISBN 978-1-4200-1378-8.
  43. ^ Prasad, Ramjee; Mihovska, Albena (2009). New Horizons in Mobile and Wireless Communications: Networks, services, and applications. Vol. 2. Artech House. p. 339. ISBN 978-1-60783-970-5.
  44. ^ "Draft-pruss-DHCP-auth-DSL-07 - EAP Authentication Extensions for the Dynamic Host Configuration Protocol for Broadband". Archived from the original on 2015-04-03. Retrieved 2013-12-12.
[edit]
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Dynamic_Host_Configuration_Protocol&oldid=1262983453"