DHCP

DHCP gives a device the network settings it needs to communicate. The name stands for Dynamic Host Configuration Protocol.

Without DHCP, you would enter an address and related settings on every device. That approach can work for a few stable systems. It becomes slow and error-prone when laptops, phones, virtual machines, and other clients appear and disappear.

DHCP centralizes that work. A client asks for configuration. A server selects settings for that client. The result is a binding between the client and a collection of parameters.

The core problem

An IP address alone is rarely enough. An IPv4 client commonly also needs a subnet mask, a default router, and one or more DNS server addresses. DHCP carries these values as options.

The server can allocate an address for a limited period called a lease. A lease lets the server reuse an address after the client stops using it. The client can request an extension before the lease expires.

DHCP also supports fixed allocation. An administrator can arrange for a known client to receive stable parameters. DHCP is therefore more than random address assignment. It is a protocol for controlled delivery of host configuration.

The four roles

The client requests configuration. It usually begins before it has a usable address.

The server manages bindings and returns configuration. One network can have more than one server.

The relay agent passes DHCP messages between a client network and a server on another network. This role avoids placing a server on every physical segment.

The administrator defines address pools, exclusions, reservations, options, lease policy, and relay placement. DHCP automates delivery, but it does not choose sound policy for you.

The DHCPv4 exchange

A new DHCPv4 client normally follows four steps:

1. It broadcasts DHCPDISCOVER to locate servers.
2. A server returns DHCPOFFER with an address and configuration.
3. The client sends DHCPREQUEST to select one offer.
4. The selected server sends DHCPACK to confirm the binding.

You may see this sequence shortened to DORA: Discover, Offer, Request, Acknowledge. The abbreviation helps you remember the order. The message names matter more during troubleshooting.

The client can receive a DHCPNAK when a requested address or configuration is not valid. It can send DHCPDECLINE after detecting that an offered address is already in use. It can send DHCPRELEASE when it no longer needs a lease, although correct server operation cannot depend on every release arriving.

DHCPv4 uses UDP. Clients send to server port 67, and servers send to client port 68. Initial client traffic is often broadcast because the client does not yet have a usable address or know the server.

Leases are a lifecycle

Treat a lease as a time-bounded state relationship, not as permanent ownership.

After the initial exchange, the client enters a bound state. At renewal time, it tries to extend the lease with the server that granted it. If that attempt fails, the client later enters rebinding and tries any available server. If the lease expires without acknowledgment, the client must stop using the address and restart configuration.

This lifecycle explains several operational symptoms. A client can keep working during a short server outage because its lease remains valid. A longer outage can eventually remove connectivity as leases expire. A stale server database can create conflicts or unexpected address changes.

Options carry the useful settings

DHCPv4 options use code, length, and value fields. The option code identifies the setting. Common examples include subnet mask, router, DNS server, requested address, lease time, message type, server identifier, renewal time, and rebinding time.

Do not memorize every code. Learn the common ones, then check the IANA registry and the defining RFC when you need an exact meaning. The registry changes as new options are assigned.

The client can send a parameter request list. The server returns as many requested parameters as it can provide. A successful address lease does not prove that every requested option was present or correct.

Relays cross routed boundaries

Routers normally separate broadcast domains. A client broadcast on one subnet therefore does not automatically reach a server on another subnet.

A relay agent receives the local request and passes it to a server. For DHCPv4, relay information includes the gateway address field. The server uses relay context to select configuration for the correct client subnet and sends the response back through the relay.

When one subnet fails while others work, inspect the relay path before blaming the shared server. A missing relay, a blocked UDP path, or incorrect subnet mapping can isolate one client network.

DHCPv6 is not DHCPv4 with larger addresses

DHCPv6 is a separate protocol for IPv6. The current standard is RFC 9915. It can provide configuration without addresses, assign non-temporary addresses, and delegate prefixes.

DHCPv6 can operate in place of or alongside Stateless Address Autoconfiguration, usually called SLAAC. Router Advertisements remain part of the IPv6 control plane. Do not assume that a DHCPv6 server supplies the IPv6 default router in the same way that a DHCPv4 server commonly supplies the router option.

The normal stateful DHCPv6 exchange is Solicit, Advertise, Request, and Reply. Clients listen on UDP port 546. Servers and relay agents listen on UDP port 547. The names, ports, multicast behavior, identifiers, and option formats differ from DHCPv4.

Where DHCP fits

DHCP works well for user devices, guest networks, lab systems, virtual machines, and other populations where centralized policy and address reuse matter.

Stable infrastructure can still use DHCP reservations. A reservation keeps configuration centralized while giving a known client a predictable address. Manual static configuration remains useful when a system must start without DHCP or when the network design explicitly requires local configuration.

DHCP does not replace DNS. DHCP can tell a client which DNS servers to use and can participate in workflows that update DNS. DNS still maps names and addresses.

DHCP also does not prove identity or authorize network access. It distributes configuration. Network admission, switch security, segmentation, and monitoring solve different problems.

Limits and risks

An unauthorized server can provide false addresses, routers, or DNS servers. A malicious client can also consume address resources. DHCP availability and trust therefore affect the entire client population.

Use network controls that restrict where server replies can enter the client network. Protect relay-to-server paths where the design requires it. Monitor address-pool use, server health, rejected requests, conflicts, and lease churn.

Address conflict detection adds another safeguard. An IPv4 client can probe an offered address with ARP. If the address is already in use, the client reports a conflict instead of using it.

A practical troubleshooting model

Start with scope. Is one client affected, one subnet, or every subnet?

Then follow the exchange. Did the client send a discovery message? Did an offer return? Did the request name the intended server? Did the acknowledgment contain the correct options?

Finally, follow time. Is the client starting fresh, renewing with one server, rebinding to any server, or operating after lease expiry?

Packet captures, server logs, relay counters, and the client lease state answer different parts of the same story. Match each observation to the role and lifecycle stage.