• Glossary
  • What is DORA (discover, offer, request, acknowledge)?

DHCP glossary

What is DORA (discover, offer, request, acknowledge)?

The DORA process (discover, offer, request, acknowledge) is a DHCP message exchange that lets a client obtain an IP address and configuration from a server. It uses four messages, as defined in RFC 2131, to find servers, select one offer, and confirm the lease.

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.

The DORA process (discover, offer, request, acknowledge) is a four-message DHCP exchange defined in RFC 2131 that enables clients to obtain an IP address and network configuration from a server. Every device using DHCP relies on DORA's success, making its operational health critical to how quickly devices come online, particularly in large networks where multiple clients may start the exchange simultaneously after events like power outages. Operational failures at specific DORA steps—such as discovers with no offers, offers without acknowledgment, rogue server interference, or boot storms after outages—can be isolated through message sequence analysis in logs and packet captures, with risks mitigated through controls like DHCP snooping and redundant server configuration.

  • DHCPDISCOVER and DHCPREQUEST messages are broadcast because the client lacks a configured address, while DHCPOFFER and DHCPACK may be sent as unicast or broadcast depending on client flags and server implementation.
  • Operational faults such as missing relay configurations, exhausted scopes, asymmetric routing, or rogue servers can be diagnosed by examining the message sequence in packet captures and logs to identify which step fails.
  • DHCP snooping on access switches, lease activity monitoring, and redundant servers with adequate scope sizing protect against rogue DHCP servers, address exhaustion during boot storms, and duplicate address assignments from overlapping unconfigured scopes.

DORA process at a glance

AttributeValue
Full nameDiscover, offer, request, acknowledge
CategoryNetwork protocol exchange
Defined inRFC 2131 (Dynamic Host Configuration Protocol)
Protocol and portDHCP over UDP, server port 67 and client port 68
OSI layerApplication layer
Primary useLeasing an IPv4 address and configuration to a client
Related termsDHCP, DHCP lease, DHCP relay agent, DHCP scope, IP address management

How DORA process works

A DHCP client that has no address starts the DORA process at boot or when it joins a network. The exchange has four messages, and the first and third are normally broadcast because the client does not yet hold a configured address.

  1. Discover: The client broadcasts a DHCPDISCOVER message to find available DHCP servers on its local network segment.
  2. Offer: Each server that can serve the client replies with a DHCPOFFER containing a proposed IP address, lease duration, and other configuration options.
  3. Request: The client picks one offer and broadcasts a DHCPREQUEST that names the chosen server. Servers whose offers were not chosen can then release the addresses they reserved.
  4. Acknowledge: The chosen server sends a DHCPACK confirming the lease and the final configuration. The client then configures its interface and starts using the address.

Clients on other subnets reach servers through a DHCP relay agent, which forwards the broadcasts as unicast. A client that already holds a lease renews it later with a shortened exchange rather than repeating all four steps. A server can also reject a request with a DHCPNAK, which sends the client back to discover.

Why DORA process matters in enterprise networks

Every device that gets its address from DHCP depends on the DORA process, so its health directly affects how quickly devices come online. In large networks, many clients can start the exchange at once, such as after a power outage or at the start of a workday. A server that is slow, out of addresses, or unreachable leaves clients without connectivity.

Operational problems often show up as a failure at a particular step. Discovers with no offers point to an unreachable server, a missing relay configuration, or an exhausted scope. Offers with no acknowledgment can indicate conflicting servers or a server that no longer holds the reserved address. Reading the message sequence in logs or packet captures is a common way to isolate these faults.

The exchange has no built-in authentication in the base protocol defined in RFC 2131, so a rogue server on the segment can answer a discover and hand out bad gateways or DNS settings. A malicious client can also send many discovers with spoofed hardware addresses to exhaust a scope. Controls such as DHCP snooping on switches and monitoring of lease activity reduce these risks.

Common DORA process issues

The client sends repeated DHCPDISCOVER messages and never receives a DHCPOFFER. Common causes are a missing or wrong relay (IP helper) address on the client VLAN gateway, a firewall blocking UDP ports 67 and 68, or a scope that is exhausted or inactive.

The client receives a DHCPOFFER and sends a DHCPREQUEST, but the lease is never confirmed. The server may have reassigned the offered address, or the request may not reach the server because relay or return-path routing is asymmetric. Clients then restart the exchange.

An unauthorized device, such as a consumer router plugged into a switch port, answers DHCPDISCOVER first and hands out wrong gateways or DNS servers. Clients appear to complete DORA normally but have no working connectivity. DHCP snooping on access switches blocks offers from untrusted ports.

When several servers answer one discover, the client picks one offer, and the others should release their reserved addresses. Overlapping scopes without coordination or failover configuration can cause duplicate address assignments and address conflict reports.

After a power outage, many clients start DORA at the same moment and can overwhelm a slow server. Symptoms include delayed offers and clients falling back to link-local addresses. Adequate scope sizing, redundant servers, and reasonable lease times reduce the impact.

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

DORA process FAQ

Related terms

Article

DHCP (Dynamic Host Configuration Protocol)

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

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

DHCPREQUEST

Sent by the client to the server in response to a DHCPOFFER indicating which server the client has chosen to further interact with.

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

Dynamic IP Address

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

Learn more
Article

IPAM (IP address management)

A method for planning, tracking, and managing IP address space on a network.

Learn more
Browse the full glossary