DHCP glossary

What is DHCPOFFER?

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.

DHCPOFFER is the second message in the DHCP DORA exchange (discover, offer, request, acknowledge) that a DHCP server sends to propose an IP address lease and configuration options to a requesting client. The message is not a binding commitment; the client receives a temporary offer and must respond with a DHCPREQUEST before the server confirms the lease with a DHCPACK. Proper DHCPOFFER management is critical for network operations because offer failures, overlapping scopes, rogue servers, or incorrect configuration options can prevent endpoints from obtaining network access or cause them to receive incorrect gateway and DNS settings that disrupt connectivity.

  • DHCPOFFER is transmitted from server port 67 to client port 68 over UDP at the application layer and can be sent as unicast or broadcast depending on the broadcast flag set by the client in its DHCPDISCOVER.
  • A client may receive DHCPOFFER messages from multiple DHCP servers simultaneously and must select one by sending a DHCPREQUEST, allowing the other servers to return their offered addresses to the available pool.
  • Common operational failures include exhausted address scopes with no available addresses to offer, overlapping scope ranges between multiple servers that create duplicate address conflicts, and incorrect configuration options such as wrong gateway or DNS server values that leave clients unable to reach network resources.

DHCPOFFER at a glance

AttributeValue
CategoryDHCP message type
Defined inRFC 2131, with message type carried in the option defined in RFC 2132
Protocol and portUDP; the server sends from port 67 to client port 68
OSI layerApplication layer (layer 7)
Primary useOffering an address lease and configuration options to a client
Related termsDHCP, DHCPDISCOVER, DHCPREQUEST, DHCPACK, DORA, lease time

How DHCPOFFER works

DHCPOFFER is the second message in the DHCP DORA exchange (discover, offer, request, acknowledge). A server sends it after receiving a client's DHCPDISCOVER.

  1. Discover: A client without a lease broadcasts a DHCPDISCOVER to find available DHCP servers on its network segment.
  2. Offer: Each server that can serve the client selects an available address and replies with a DHCPOFFER. The message carries the proposed address, the server identifier and options such as lease time, subnet mask, router and DNS servers.
  3. Request: The client picks one offer and broadcasts a DHCPREQUEST naming the chosen server, which tells other servers their offers are declined.
  4. Acknowledge: The chosen server confirms the lease with a DHCPACK, and the client can then use the address.

An offer is not a commitment. The server may hold the offered address for a short time, but the client has no lease until it receives a DHCPACK. The server may unicast or broadcast the reply, depending on the broadcast flag the client set. When the client is on another subnet, a relay agent forwards the DHCPOFFER.

Why DHCPOFFER matters in enterprise networks

Every dynamically addressed device begins its lease with this exchange, so DHCPOFFER behavior affects how quickly endpoints get network access. RFC 2131 lets a client receive offers from more than one server and choose among them. That behavior is useful for redundancy, but it also means that an unintended server can answer clients.

Poor management shows up as offers that never arrive or arrive with wrong data. Exhausted scopes leave a server with no address to offer, so clients fail to connect. Overlapping scopes on multiple servers can produce offers for addresses already in use. Incorrect options in an offer, such as a wrong gateway or DNS server, give clients addresses that appear valid but cannot reach resources.

A rogue DHCP server can answer a DHCPDISCOVER with its own DHCPOFFER and steer clients to an attacker's gateway or DNS resolver. Network teams commonly counter this with DHCP snooping on switches, which permits offers only from trusted ports. Logging offers and comparing them against the authorized server list helps detect misconfigured or unauthorized servers.

DHCPOFFER vs DHCPACK

DHCPOFFER proposes a lease to a client before the client commits, while DHCPACK is the server's final confirmation that the lease is granted. What is DHCPACK?

AttributeDHCPOFFERDHCPACK
Position in DORASecond messageFourth message
Sent in response toDHCPDISCOVERDHCPREQUEST
MeaningProposed address and optionsLease confirmed and committed
Number of sendersCan come from several serversComes from the one server the client selected
Client can use the addressNoYes

DHCPOFFER vs DHCPDISCOVER

DHCPDISCOVER is the client's broadcast looking for servers, while DHCPOFFER is a server's reply proposing an address. What is DHCPDISCOVER?

AttributeDHCPOFFERDHCPDISCOVER
SenderDHCP serverDHCP client
Position in DORASecond messageFirst message
PurposeProposes an address and optionsLocates available servers
ContentProposed address, server identifier, lease optionsClient identifier and optional requests for parameters

Common DHCPOFFER issues

An unauthorized DHCP server, such as a home router plugged into a switch port, answers DHCPDISCOVER with its own offer. Clients that accept it get the wrong gateway or DNS servers, and the symptom is often limited to a few devices on one VLAN.

Clients keep sending DHCPDISCOVER and never receive an offer. Common causes are an exhausted scope, a missing or misconfigured relay agent on the router, or a firewall blocking DHCP traffic between relay and server.

Two servers with overlapping ranges can each offer the same address to different clients. The result is duplicate address conflicts that appear intermittently after a client picks one offer.

The offer carries incorrect router, DNS or lease time values because a scope or option was set at the wrong level. Clients get an address but cannot reach resources, so the fault looks like a routing or DNS problem.

DHCP snooping on a switch drops offers that arrive on untrusted ports. If the uplink toward the legitimate server is not marked trusted, no offer reaches clients.

See how unified DDI simplifies network operations

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

DHCPOFFER FAQ

Related terms

Article

DHCPDISCOVER

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

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

DORA process

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

Learn more
Article

DHCP (Dynamic Host Configuration Protocol)

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

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

Rogue DNS Server

Translates domain names of desirable websites into IP addresses of sites with unintended content.

Learn more
Article

Dynamic IP Address

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

Learn more