DHCP Explained: Static vs Dynamic IP Allocation

 The static versus dynamic debate is usually framed wrongly, and the wrong framing leads to bad decisions in real networks.

The question is not whether a device should keep the same address. Plenty of devices should. The question is where the record of that address lives — in a central database you can query, audit, and change from one place, or typed int o the device itself where nobody will ever find it again.Once you frame it that way, a third option appears that most people underuse, and it is usually the correct one.

Three Methods, Not Two

There are three ways a device can get its address, and treating this as a binary choice is the root of the confusion.

Dynamic allocation. The device asks, and the DHCP server assigns whatever is free from a pool. The address may change over time. Suitable for anything that does not need to be found at a predictable address.

DHCP reservation. The device asks, and the DHCP server always gives it the same address, matched to its MAC address. The device is configured for DHCP and knows nothing about the arrangement. From the device's perspective it is dynamic; from the network's perspective it is fixed.

Host-configured static. Someone types an address, mask, gateway, and DNS servers into the device itself. The DHCP server is not involved and does not know the address exists.

The second option gives you everything people usually want from the third, without the drawbacks. That is the central argument of this article, and it is worth stating plainly: most devices configured with host-typed static addresses should be using reservations instead.

How Dynamic Allocation Actually Works

Before the comparison, the mechanism.

A client with no address broadcasts a Discover message. Any DHCP server on the segment responds with an Offer containing a proposed address. The client broadcasts a Request for that specific address, and the server sends an Acknowledgement confirming the lease. This four-step exchange is known by the acronym DORA.

The lease is temporary and renews on a schedule:

• At 50 percent of the lease duration, the client contacts the server directly to renew. Usually this succeeds and nobody notices.
• At 87.5 percent, if the direct attempt failed, the client broadcasts to any available server.
• At 100 percent, the lease expires and the client releases the address and starts over.

This design is more resilient than it first appears. A DHCP server that goes down at midday does not disconnect anyone — existing leases continue working until they need renewal, and renewal attempts that fail simply retry. With a lease of several days, an outage can pass entirely unnoticed.

The Case for Reservations

A reservation ties a specific address to a specific MAC address in the DHCP server's configuration. The device is configured exactly like any other DHCP client.

Why this is better than typing an address into the device:

• The record is central. You can see every assigned address in one place, search it, export it, and back it up with the rest of the server configuration.
• Changing the scheme is possible. Renumbering a subnet means editing the server, not visiting forty devices.
• Options are distributed automatically. Change your DNS servers and every device picks up the change at its next renewal. Statically configured devices keep pointing at the old ones until someone visits each of them.
• Conflicts cannot happen. The server knows the address is allocated and will not offer it to anything else.
• Replacement is simpler. A failed device is replaced by updating one MAC address in one place.
• It self-documents. The reservation list is an inventory, maintained as a side effect of doing the work.

Devices that should almost always have reservations rather than typed addresses: printers, access points, IP cameras, VoIP phones, network-attached storage, building systems, and most application servers.

When Host-Configured Static Is Genuinely Right

Reservations are not universally correct. Some devices must have an address before any DHCP conversation can occur:

• The DHCP server itself. It cannot lease an address to itself before it is running.
• DNS servers, which clients need in order to function and which should not depend on another service.
• Routers, switches, and firewalls. Infrastructure that must be reachable when other services have failed — including during the outage you are trying to fix.
• Anything on a segment with no DHCP service, such as an isolated management network.
• Devices whose MAC address changes, including some virtual machines and anything using randomised hardware addresses.
• Out-of-band management interfaces, which exist precisely for when the network is broken.

The unifying principle: if a device needs to be reachable while DHCP is unavailable, it cannot depend on DHCP. Everything else can.

The Problems Static Addressing Creates

Worth listing explicitly, because these accumulate quietly over years:

• No central record. Someone assigned 10.0.0.47 to something in 2019. Nobody knows what. Nobody dares reuse it.
• Duplicate addresses. Two devices with the same address produce intermittent failures affecting both, and the symptom is baffling because it comes and goes.
• Stale configuration. Devices pointing at DNS servers that were decommissioned, discovered only when something finally breaks.
• Renumbering becomes impossible. Changing a subnet requires physically touching every statically configured device.
• Documentation drift. The spreadsheet was accurate once.
• Invisible devices. A device with a typed address does not appear in the DHCP lease list, so it is invisible to anyone auditing the network from the server.

That last point matters for security as much as for administration. If your view of what exists on a network comes from DHCP, statically addressed devices are simply absent from it.

Designing the Address Plan

A subnet should be divided deliberately rather than filled randomly. A workable scheme for a /24:

1. .1 to .10 — network infrastructure. Gateway, switches, firewall, wireless controller. Typed static.
2. .11 to .30 — servers. Typed static for the critical ones, reservations for the rest.
3. .31 to .99 — reservations. Printers, access points, cameras, phones, and anything else that needs a predictable address.
4. .100 to .240 — the dynamic pool. Laptops, phones, visitors, anything transient.
5. .241 to .254 — reserved for future use. Leave room. You will need it.

The critical step that people skip: configure exclusions in the DHCP scope covering every statically addressed range. If the pool overlaps addresses that are typed into devices, the server will eventually hand one of them to a laptop and produce a duplicate address conflict that takes hours to trace.

Choosing a Lease Duration

Lease time is a genuine design decision with real consequences in both directions.

Shorter leases — hours rather than days — suit environments with high device turnover: guest networks, public wireless, training rooms, conference venues. Addresses return to the pool quickly, which prevents exhaustion.

Longer leases — a week or more — suit stable environments where the same devices connect every day. They reduce DHCP traffic, keep addresses consistent enough to be useful in logs, and provide genuine resilience if the server becomes unavailable.

Practical guidance: eight days is a common default and works well for office networks. Guest and wireless networks with heavy visitor traffic often work better at two to four hours. If scope utilisation is climbing toward exhaustion, shortening the lease is the fastest intervention available.

A Note on IPv6

The rules change in ways worth knowing, because IPv6 is already running on most networks whether or not anyone configured it.

IPv6 offers a third assignment mechanism that has no IPv4 equivalent: stateless address autoconfiguration, usually shortened to SLAAC. The router advertises the network prefix, and each device constructs its own address from that prefix plus an identifier it generates locally. No server is involved and no lease is recorded anywhere.

That is efficient and, from an administrative perspective, awkward — because nothing centrally records which device holds which address.

The options in practice:

• SLAAC alone. Devices self-configure. Simple, and no record exists.
• DHCPv6 alone. Stateful assignment resembling IPv4 DHCP, with leases recorded centrally. Notably, Android devices have historically not supported DHCPv6, which constrains this approach on networks with mobile devices.
• SLAAC with stateless DHCPv6. Devices self-configure their address and obtain DNS settings from DHCPv6. A common compromise.

Two practical warnings. Privacy extensions cause devices to generate temporary addresses that rotate regularly, which makes address-based logging and firewall rules considerably less useful than administrators expect. And a network with IPv6 enabled but unmanaged is a network where traffic may be flowing entirely outside your IPv4 firewall rules — which is worth checking rather than assuming.

Mistakes That Recur

• Pool overlapping static assignments. The most common and most disruptive error.
• Reservations created for the wrong MAC address, usually the wireless adapter instead of the wired one, or vice versa.
• Assuming a reservation applies immediately. The device keeps its current address until the existing lease expires or is released.
• Forgetting that laptops have two adapters, each with its own MAC address and therefore needing two reservations if the machine should be predictable on both.
• Using static addressing "because it is more reliable." It is not. It is less visible, and invisibility is not reliability.
• Randomised MAC addresses on phones breaking reservations silently. Most devices allow this to be disabled per network, and it usually should be for managed networks.

The Rule Worth Remembering

Ask one question about any device: does it need to be reachable when DHCP is unavailable?

If yes — infrastructure, DNS, the DHCP server itself — type the address into the device.

If no — and this covers the overwhelming majority of everything else, including devices that need a fixed address — use a reservation.

That single distinction resolves most of what people find difficult about static vs dynamic IP allocation, and it leaves you with a network where the address plan lives in a database rather than in the memories of people who left three years ago.