• Glossary
  • What is DHCPNACK (DHCP negative acknowledgment)?

DHCP glossary

What is DHCPNACK (DHCP negative acknowledgment)?

DHCPNAK (DHCP negative acknowledgment) is a DHCP message type that a server sends to reject a client's DHCPREQUEST. It tells the client that the requested address is incorrect or no longer valid, so the client must stop using it and restart the discovery process, as defined in RFC 2131.

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.

DHCPNAK (DHCP negative acknowledgment) is a standard DHCP message type defined in RFC 2131 that a server sends to reject a client's DHCPREQUEST when the requested address is invalid, unavailable, or no longer applicable to the client's current network. When a client receives a DHCPNAK, it must stop using the rejected address and restart the DHCP discovery process to obtain valid configuration parameters. Monitoring DHCPNAK rates serves as an operational signal to detect network issues such as client roaming, lease database synchronization problems, misconfigured relay agents, or overlapping DHCP scopes before they cause user-facing connectivity loss.

  • DHCPNAK carries no address or lease information and includes only a message option and server identifier, forcing the client to return to initial discovery state rather than binding any configuration.
  • High or sustained DHCPNAK rates indicate specific network problems such as lost lease databases after server rebuilds, relay agent misconfiguration with incorrect gateway addresses, or overlapping address scopes in failover pairs.
  • DHCP snooping on network switches mitigates rogue server attacks by restricting DHCP server messages to trusted ports, preventing unauthorized servers from forging DHCPNAK messages to disrupt valid client leases.

DHCPNAK at a glance

AttributeValue
Full nameDHCP negative acknowledgment
CategoryNetwork protocol message
Defined inRFC 2131
Protocol and portDHCP over UDP, server port 67 and client port 68
OSI layerApplication layer
Primary useRejecting a client's address request so it restarts configuration
Related termsDHCP, DHCPREQUEST, DHCPACK, DHCPDISCOVER, DHCPOFFER, lease

How DHCPNAK works

A server sends a DHCPNAK when it cannot honor a DHCPREQUEST. The message tells the client that the address or parameters it asked for are not usable on its current network.

  1. Client sends a request: The client sends a DHCPREQUEST, either to accept an offer, to confirm an address it remembers after a reboot, or to renew or rebind an existing lease.
  2. Server checks the request: The server compares the requested address with its configuration and lease records. The request fails if the address is not valid for the client's subnet, is already allocated to another client, or is otherwise unavailable.
  3. Server sends DHCPNAK: Instead of a DHCPACK, the server returns a DHCPNAK. When a relay agent is involved, the message is returned through the relay to the client.
  4. Client restarts: On receiving the DHCPNAK, the client stops using the address and returns to the initial state, where it sends a new DHCPDISCOVER to obtain a valid configuration.

A DHCPNAK can include a message option explaining the refusal, but it carries no address or lease. Clients should treat it as final for that request and not keep using the rejected address.

Why DHCPNAK matters in enterprise networks

The DHCPNAK is the mechanism that keeps clients from using stale or wrong addresses. A common case is a laptop that moves to a different subnet and tries to confirm the address from its previous network. The server rejects it with a DHCPNAK, and the client gets a correct address instead of failing with an address that cannot work. RFC 2131 defines this behavior as part of normal client and server operation.

Frequent DHCPNAKs are a useful signal in operations. They can point to clients roaming between networks, lease databases that have been lost or are out of sync, misconfigured relay agents, or two servers handing out overlapping ranges. In failover pairs, mismatched state can cause one server to reject requests that its partner granted. Monitoring DHCPNAK rates helps teams find these problems before users report connectivity loss.

There are security implications as well. A rogue DHCP server or an attacker on the local network can forge a DHCPNAK to force clients off valid leases, causing disruption. Features such as DHCP snooping on switches limit server messages to trusted ports and reduce this risk.

DHCPNAK vs DHCPACK

A DHCPACK confirms that the client may use the address and parameters it requested, while a DHCPNAK rejects the request and forces the client to start over. What is DHCPACK?

AttributeDHCPNAKDHCPACK
PurposeRejects a DHCPREQUESTAccepts a DHCPREQUEST
Sent byDHCP serverDHCP server
Client action afterwardStops using the address and restarts discoveryBinds the address and starts lease timers
Carries configuration optionsNo, apart from a message and server identifierYes, including lease time and other options

DHCPNAK vs DHCPOFFER

A DHCPOFFER proposes an address in reply to a DHCPDISCOVER, while a DHCPNAK rejects a DHCPREQUEST that the server cannot honor. What is DHCPOFFER?

Common DHCPNAK issues

A client repeatedly receives a DHCPNAK and restarts discovery without getting a lease. This often happens when the server and the client's subnet disagree, such as a missing or wrong scope on the relay path.

An unauthorized DHCP server on the segment can answer a legitimate client's request with a DHCPNAK. Clients then fail to renew valid leases, and the cause is hard to find until packet captures show the unexpected server identifier.

After a server rebuild or failover without synchronized lease data, the server may not recognize addresses clients still hold. Clients renewing those leases receive NAKs in bursts, which shows up as a spike in rejections.

If the relay agent sets the wrong gateway address, the server picks a scope that does not match the client's real subnet. It then rejects requests for the address the client holds, and clients on that VLAN lose connectivity.

Two servers that are not coordinated can hand out the same address, or one can reject a request for a lease the other issued. Clients see intermittent NAKs and address conflicts.

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

DHCPNAK FAQ

Related terms

Article

DHCP (Dynamic Host Configuration Protocol)

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

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

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

DHCPDISCOVER

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

Learn more
Article

DORA process

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

Learn more
Article

Dynamic IP Address

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

Learn more
Article

Subnet mask

A 32-bit number that masks an IP address, and divides the IP address into network address and host address.

Learn more
Browse the full glossary