The question surfaces the moment something on the network has to be found again at the same place tomorrow. A network video recorder needs its cameras to answer at predictable addresses so a channel does not go dark after a power blip; a print server has to sit where every workstation's queue already expects it; a firewall rule that whitelists a site-to-site VPN endpoint breaks the day that endpoint's address moves. It also surfaces at the circuit itself: a branch office that will host its own mail gateway, or expose any inbound service, discovers that a standard broadband line hands out an address that changes over time — or, increasingly, is not a real public address at all. The decision is per-device and per-role, never one setting applied to the whole site.
Three questions decide each case. First, does anything need to initiate a connection to this device — a user opening a camera feed, a partner firewall reaching a tunnel endpoint, a workstation printing — or does the device only ever reach outward? Things that must be reachable need a stable address; pure clients do not. Second, is that reachability inside the LAN or across the public internet, because a fixed internal address (from an RFC 1918 range such as 192.168.x.x) is free to assign, while a fixed public address is an ISP line item and often a business-class upgrade. Third, if the address does stay fixed, should the device hold it itself or should the DHCP server hand it the same one every lease — the difference between a hand-configured static and a DHCP reservation, and it hinges on whether the device must still work when DHCP is down.
At a glance
Side by side
| Factor | Static IP | Dynamic IP |
|---|---|---|
| How it's assigned | Fixed by hand on the device, or reserved on the DHCP server | Leased from a DHCP pool for a renewable, time-limited period |
| Reachability | Always answers at the same address; safe to point rules and bookmarks at | Address can change at renewal, so inbound references may break |
| Best-fit devices | Servers, printers, cameras, switches, gateways, port-forward targets | Laptops, phones, most desktops and other client endpoints |
| Admin effort | Manual config must be tracked per device to avoid collisions | Pool assigns and reclaims addresses automatically; low touch |
| Address conflicts | Possible if two devices are hand-set to the same address | Server owns the pool, so duplicate assignments are avoided |
| Public-facing cost | A static public IP is typically an ISP add-on or business-class line | Standard lines use dynamic or CGNAT-shared public addresses |
| Documentation | Must be recorded in an address plan / IPAM to stay auditable | Bindings live on the DHCP server; less to hand-document |
| Failure behavior | Holds its address even if DHCP service is down | No DHCP and no other config yields a 169.254.x.x self-assigned address |
Choose a fixed address (static or reservation) when
- Something initiates connections to the device — an NVR pulling camera streams, a print server, or a management console staff reach by address rather than by name.
- A firewall rule, port-forward, or partner VPN whitelist references the device, so a silently changed address would break access with no obvious cause.
- It is core infrastructure the network depends on to boot — the DHCP server, the default gateway, or the primary DNS resolver — which must be hand-set static because it has to answer even when DHCP itself is down.
- You are provisioning a public-facing service — on-prem mail, web, or a VPN concentrator — that needs a routable static public IP from the ISP, not just a fixed internal one.
Leave it on a dynamic lease when
- The device is a client that only ever reaches outward — laptops, phones, tablets, and most desktops that never need to be found at a known address.
- The endpoint churns through the fleet on a refresh cycle, where hand-tracking addresses would create more conflicts than it ever prevents.
- You are covering guest, BYOD, or high-density Wi-Fi, where a pool that leases and reclaims addresses automatically is the only manageable approach.
- A device must stay findable but does not run the network itself — reserve its address on the DHCP server rather than hand-configuring, so it lands on the same IP each lease yet stays centrally managed.
Bottom line
Decide per device, by role, not by preference. The default for the whole client fleet is dynamic — a DHCP lease is lower-touch and avoids the address collisions that hand-configuration invites. For the devices that must be findable — printers, cameras, most servers, network gear — the right tool is usually a DHCP reservation rather than a hand-set static: the address stays put, but it is managed centrally and inventoried on the server. Reserve true device-configured static IPs for the narrow set the network itself depends on — the DHCP server, core gateways, and primary DNS — because a reservation is worthless if DHCP is down and there is nothing to ask. Separately, only spec a static public IP from the ISP where you actually host an inbound service; internal statics come free from private ranges. Whichever you pick, record it: an accurate address plan is the difference between a five-minute change and an outage — and, in audited environments, part of the system inventory a network diagram is expected to reflect.
Shop it at Uniqcli
FAQ
Common questions
- Do I need a static IP for a home security camera, NVR, or DVR?
- On the local network, yes — but a DHCP reservation is a better way to get it than a hand-configured static. The recorder pulls each camera's stream by address, so if a camera's IP changes at lease renewal, that channel goes dark; giving every camera and the recorder a fixed internal address keeps the feeds stable. Reserving those addresses on the router or DHCP server does exactly this while keeping them centrally managed. A static public IP from the ISP is a separate question — you only need that to reach the system remotely without a dynamic-DNS workaround, not for the cameras to talk to the recorder on the LAN.
- Why does my device show a 169.254.x.x IP address?
- A 169.254.x.x address means the device tried to get a lease from a DHCP server, got no answer, and self-assigned a link-local address instead. This range — defined by RFC 3927 and often called APIPA — is what a host falls back to when no DHCP server or other configuration is reachable; it probes the segment to avoid a conflict, then picks an address in that block. It signals a DHCP problem, not a working setup: a dead server, an unplugged cable, a bad switch port, or a VLAN with no DHCP relay. Devices in this state can usually only reach others that also self-assigned on the same segment.
- How much does a static IP address cost from an ISP?
- There is no universal price, but a static public IP almost always costs more than a standard dynamic connection — usually as a business-class plan or an added monthly fee. Providers charge for it because dynamic and CGNAT-shared addressing lets them reuse a limited pool of public IPv4 addresses across many customers, whereas a dedicated static address is taken out of circulation for you. For a site hosting several inbound services, an ISP often sells a small routable block, such as a /29, rather than a single address. Internal static addresses on your own LAN, by contrast, cost nothing — they come from private ranges you assign yourself.
- Can I set up port forwarding without a static IP?
- Yes — port forwarding works with a dynamic public IP, as long as it is a real public address; you just pair it with dynamic DNS so a hostname follows the address whenever it changes. The bigger obstacle today is Carrier-Grade NAT (CGNAT): many residential and small-business plans hand out an address from a shared range — 100.64.0.0/10, defined by RFC 6598 — rather than a genuine public one, and port forwarding cannot work through it no matter how the router is configured. Confirm you actually have a public address first; if you are behind CGNAT, you will need to request a real public IP — static or dynamic — from the ISP, not just change a setting.