DHCP glossary

What is DHCPREQUEST?

DHCPREQUEST is a Dynamic Host Configuration Protocol message that a client sends to ask a server for specific configuration parameters, most often an IP address lease. It selects one server's offer, confirms a remembered address after a reboot, or extends an existing lease during renewal and rebinding.

Let's simplify your DDI
Abstract isometric UI showing network ranges, usage bars, region names (EMEA/APAC), and a purple "Deploy" button
Key takeawaysKey takeaways are generated with AI assistance. Because automated summaries can occasionally contain errors or miss important context, always refer to the full blog post for complete information.

DHCPREQUEST is a Dynamic Host Configuration Protocol message sent by clients to request specific configuration parameters, most commonly an IP address lease, operating as the critical third step in the DORA exchange where a lease becomes binding only after the server replies with DHCPACK. The message serves multiple operational roles including selecting from multiple server offers, confirming addresses after reboot, and renewing expiring leases, with its handling directly impacting server load, network troubleshooting, and security posture. On large networks with thousands of clients, the volume and timing of DHCPREQUEST messages shape server performance, while protocol vulnerabilities and common failure modes such as relay agent problems, stale caches, and rogue servers require careful packet analysis and monitoring to diagnose and prevent address conflicts, exhaustion attacks, and service disruption.

  • DHCPREQUEST becomes binding only when the server responds with DHCPACK, and until that confirmation arrives the client must not use the offered address.
  • The message operates in different modes—broadcast when selecting a server offer, unicast during renewal to the original server, and broadcast during rebinding—requiring distinct relay agent and firewall configurations for each case.
  • Security teams must recognize that DHCPREQUEST is unauthenticated in the base protocol, enabling rogue servers to answer and distribute false gateways or DNS servers, though DHCP snooping and request logging can help detect spoofing and address exhaustion attacks.

DHCPREQUEST at a glance

AttributeValue
Full nameDHCPREQUEST
CategoryNetwork protocol message
Defined inRFC 2131
Protocol and portUDP, server port 67 and client port 68
OSI layerApplication layer (layer 7)
Primary useAccepting a DHCP offer, confirming an address, or renewing a lease
Related termsDHCP, DHCPDISCOVER, DHCPOFFER, DHCPACK, DHCPNAK, DORA, lease

How DHCPREQUEST works

A client sends DHCPREQUEST in several situations, and the contents of the message differ in each. The best known case is the third step of the initial DORA exchange, as described in RFC 2131.

  1. Selecting a server: After sending DHCPDISCOVER, the client may receive offers from several servers. It picks one and broadcasts a DHCPREQUEST that includes the server identifier of the chosen server and the offered address.
  2. Informing other servers: Because the message is broadcast, servers whose offers were not chosen see the server identifier, recognize the rejection, and can release the address they had reserved.
  3. Receiving the response: The chosen server replies with DHCPACK to confirm the lease and deliver configuration options. It replies with DHCPNAK if it can no longer grant the address.
  4. Renewing or rebinding: When a lease nears expiry, the client sends DHCPREQUEST again. At the renewal time it unicasts to the original server, and at the rebinding time it broadcasts to any server.

A client that reboots and remembers a prior lease may also send DHCPREQUEST without a DHCPDISCOVER, to confirm that the address is still valid on the current network. In that case no server identifier is included, so any server that knows the binding can answer.

Why DHCPREQUEST matters in enterprise networks

DHCPREQUEST is the point where a lease becomes binding. Until the server answers it with DHCPACK, the client must not use the offered address. On networks with thousands of clients, renewal requests arrive continuously, so the volume and timing of these messages shape server load. Short lease times raise the number of DHCPREQUEST messages and the traffic on the server.

Troubleshooting depends on reading this message correctly. A client that sends repeated DHCPREQUEST messages and receives DHCPNAK is usually holding an address that is wrong for its current subnet, for example after moving between VLANs. Missing replies often point to a relay agent problem, a server that is down, or a scope that has run out of addresses. Packet captures that show the server identifier option reveal which server the client chose.

Security teams care because DHCPREQUEST is unauthenticated in the base protocol. A rogue server can answer a client and win the exchange, handing out a false gateway or DNS server. Switch features such as DHCP snooping limit this by trusting server replies only on approved ports, and logging DHCPREQUEST activity helps detect address conflicts, spoofing, and exhaustion attacks.

DHCPREQUEST vs DHCPDISCOVER

DHCPDISCOVER is the client's first broadcast that looks for available servers, while DHCPREQUEST asks for specific parameters, such as accepting one server's offer or extending an existing lease. What is DHCPDISCOVER?

AttributeDHCPREQUESTDHCPDISCOVER
PurposeRequests a specific address and optionsLocates DHCP servers and starts the exchange
Position in DORAThird messageFirst message
Sent in renewalYes, usually unicast to the leasing server at renewalNo
Contains server identifierYes when selecting an offerNo, because no server has been chosen
Expected replyDHCPACK or DHCPNAKDHCPOFFER

DHCPREQUEST vs DHCPACK

DHCPREQUEST is the client's ask for configuration, and DHCPACK is the server's reply that confirms the lease and delivers the options. What is DHCPACK?

AttributeDHCPREQUESTDHCPACK
SenderClientServer
RoleAsks for or confirms parametersGrants the lease and supplies options
Effect on address useClient may not use the address yetClient may begin using the address

Common DHCPREQUEST issues

A client that moved to another VLAN or subnet often still requests its old address and gets a DHCPNAK each time. It normally recovers by restarting discovery, but a client that keeps retrying points to a stale cache or a wrong scope on the server.

Broadcast DHCPREQUEST messages never reach the server if the relay agent is missing or its helper address is wrong. Clients then time out, and packet captures show requests on the client VLAN with no reply.

A rogue or misconfigured second server can send DHCPNAK or conflicting offers in response to requests. Clients lose valid leases or get wrong gateways and DNS settings, and the server identifier in captured requests shows which server was chosen.

Very short lease times or many clients rebooting together produce bursts of DHCPREQUEST messages that slow server responses. Lengthening leases or staggering restarts reduces the peak.

In a failover pair, a partner that lacks current lease data may answer a renewal with DHCPNAK, or ignore it. Clients drop their address, so check the failover state and lease synchronization first.

See how unified DDI simplifies network operations

Manage DNS, DHCP and IP addresses from one platform with automation, visibility and control built in.

Talk to us

DHCPREQUEST FAQ

Related terms

Article

DORA process

The sequence of discover, offer, request, and acknowledge messages exchanged between client and server for DHCP.

Learn more
Article

DHCPDISCOVER

Sent by the client as the first step of the DHCP client/server interaction to discover what servers exist.

Learn more
Article

DHCPOFFER

Sent by the server to the client in response to a DHCPDISCOVER to offer an IP address, lease time, and network configuration parameters.

Learn more
Article

DHCPACK

Sent by the server to the client in response to a DHCPREQUEST indicating that the server acknowledges the request.

Learn more
Article

DHCPNACK

Sent by the server to the client in response to a DHCPREQUEST indicating that the server does not acknowledge the request.

Learn more
Article

DHCP (Dynamic Host Configuration Protocol)

The standard mechanism to dynamically assign IP addresses within a network.

Learn more
Article

Dynamic IP Address

An IP address that changes from time to time, unlike a static IP address.

Learn more
Article

Time to Live (TTL)

A setting for each DNS record that specifies how long a resolver is supposed to cache the DNS query before it expires.

Learn more
Browse the full glossary