DHCP, Static, or Reservation? Deciding How Every Device Gets Its Address

Every device that joins a network needs an IP (Internet Protocol) address before it can do anything, and there are exactly three ways it can get one. It can ask a server to assign one automatically, it can have one typed into its settings by hand, or it can use a hybrid where the server always answers with the same address. Those three options are called DHCP, static assignment, and DHCP reservation, and choosing the wrong one for a device sits behind some of the most familiar small-network miseries: the printer that vanishes every Monday morning, the security camera nobody can find, the two machines that take turns knocking each other offline. This guide gives you a simple framework for deciding which method each device deserves, then shows how to lay out a subnet so the methods never collide.

DHCP stands for Dynamic Host Configuration Protocol, and it is the reason you can join a coffee shop's Wi-Fi without typing anything. When a device connects, it broadcasts a request asking for an address. A DHCP server, often built into the router on small networks, picks a free address from a range called a pool (some vendors say "scope") and offers it as a lease, a temporary loan with an expiration time. Along with the address itself, the lease carries the other settings a device needs: the subnet mask, the gateway for reaching other networks, and the DNS (Domain Name System) servers that translate names like ipcraft.io into addresses. The device renews the lease periodically while it stays connected, and once it leaves and the lease expires, the address returns to the pool for the next arrival.

For devices that come and go, this arrangement is perfect. Nobody wants to hand-configure every laptop, phone, and tablet that walks through the door, and DHCP also gives you one central place to change network settings: update the DNS entry on the DHCP server, and every client picks up the change at its next renewal. The trade-off is stability. A device's address can change whenever its lease cycles, which matters not at all for a laptop browsing the web and matters enormously for a printer that forty computers are configured to find at one specific address.

Static assignment sits at the other extreme. You open the device's own network settings and type in an address, mask, gateway, and DNS servers, and the device uses them until someone changes them, no server involved. That independence is the whole appeal. A statically configured switch keeps its address through a power outage, a DHCP server crash, or a complete network rebuild, which is exactly what you want for equipment the rest of the network depends on. The costs are just as clear. The configuration lives only on the device itself, so no central record exists unless you write one down, and hand-kept records drift out of date in all the ways we cataloged in our look at spreadsheet-based IP management. Mistype an address that is already in use and you have created an address conflict, a problem that knocks both devices offline intermittently and is famously miserable to track down.

A DHCP reservation splits the difference. Every network interface has a MAC (Media Access Control) address, a hardware identifier assigned at the factory, and a reservation is a rule on the DHCP server that says: when this particular MAC asks, always hand out this particular address. The device itself stays in automatic mode, exactly like a laptop, yet receives the same address every time it connects. You get DHCP's central management, since the assignment lives on the server instead of in the device's settings, along with static-like stability. Two dependencies are worth knowing. The device only holds an address while the DHCP server is reachable, and if you ever replace the hardware, the new unit arrives with a new MAC, so the reservation has to be updated to follow it.

With the three methods clear, the framework comes down to two questions about each device. First: what breaks if this device's address changes? Second: does this device need to work even when the DHCP server is down? Anything where the answer to the second question is yes gets a static address, and that list is short. Routers, switches, firewalls, DNS servers, and the DHCP server itself (which obviously cannot ask itself for an address) form the network's bootstrap layer, the equipment that has to come up first and stay up no matter what else fails. Many teams also include their most critical servers here, such as the virtualization hosts that everything else runs on.

Devices where only the first question bites, meaning other machines find them at a fixed address but they are not part of the bootstrap layer, are ideal candidates for reservations: printers, NAS (network-attached storage) boxes, security cameras, badge readers, wireless access points, conference room displays, lab instruments. If the DHCP server is down, the network has bigger problems than a missing printer, so the dependency costs you little, and the assignment stays centrally managed and centrally visible. Everything else, every device where neither question matters, belongs in the dynamic pool: laptops, phones, tablets, guest devices, anything that roams. The whole framework fits in one table.

The last piece is laying out the subnet so the methods never collide, and the rule is simple: give each method its own contiguous range, and configure the DHCP pool to cover only its own slice. Most address conflicts on small networks trace back to a pool that overlaps the static range. The DHCP server knows nothing about the addresses you typed into devices by hand, so sooner or later it leases one of them to a passing laptop, and the laptop and your file server begin taking turns owning the address. Here is a clean layout for a /24 network, a block of 254 usable addresses (our visual guide to CIDR notation explains where that number comes from), that keeps every method in its own lane with room to grow.

Carving a /24 so static, reserved, and dynamic never overlap

192.168.10.0/24                (254 usable addresses)
.1             Gateway (static)
.2   – .19     Network gear: switches, firewall, Wi-Fi (static)
.20  – .59     Servers and virtualization hosts (static)
.60  – .99     Reservations: printers, cameras, NAS
.100 – .239    DHCP pool (dynamic leases)
.240 – .254    Held in reserve

The exact boundaries matter far less than having boundaries at all, and the convention of putting infrastructure low and the pool high pays off across every subnet you ever run, a theme our worked example of designing an IP plan from scratch develops at length. Lease duration deserves a quick word while you are in the DHCP settings. Short leases (an hour or so) suit guest networks where strangers churn through constantly and you want addresses recycled quickly, while longer leases (one to seven days) suit office networks where the same devices return daily and there is no reason to make them renegotiate constantly. The pressure to shorten leases only appears when a pool runs near exhaustion, and if your pool of 140 addresses is running out, the better fix is usually a bigger pool or a second subnet rather than a frantic lease timer.

One footnote about the future: IPv6 (Internet Protocol version 6, the successor to the addressing system described above) reshuffles this whole topic. Its SLAAC mechanism (Stateless Address Autoconfiguration) lets devices generate their own addresses with no server and no pool, so the careful carving in this post is largely an IPv4 concern. Our guide to IPv6 address planning explains how assignment works when address scarcity disappears.

Whichever method each device ends up with, the assignment only stays healthy if it is recorded somewhere authoritative, and the method itself belongs in that record. Six months from now, the question will be "is .47 safe to hand out?", and the answer depends entirely on whether .47 is a forgotten static assignment, a reservation, or just an old lease that expired. This is the bookkeeping an IPAM (IP Address Management) tool exists to do. IPCraft tracks a status for every address in a subnet, lets you record whether each one is static, reserved, or dynamic, and supports custom fields for whatever else matters to you, like the MAC behind a reservation or the ticket that requested it, so the DHCP pool boundaries and the static ranges live in the same view instead of in three people's heads. If you are still deciding whether you need that kind of tool, our list of signs you've outgrown manual IP tracking is a fair test.

The framework compresses nicely. Give static addresses to the bootstrap layer that must survive a DHCP outage, give reservations to anything other machines find by address, and let everything that roams draw from the pool. Carve the subnet so each method owns a contiguous range, keep the pool strictly inside its slice, and write all of it down somewhere that stays current. Networks managed this way produce remarkably few mystery outages, and the ones that do occur get solved by looking at a record instead of unplugging things one at a time.