DHCP reservations and stable server addresses

A DHCP reservation binds a chosen server-side client identity to a stable address allocation while the client continues obtaining its network configuration through DHCP.

A port-forward or saved app connection needs a stable destination. If the server’s DHCP allocation changes, an otherwise correct reference can keep pointing to the old address.

A DHCP reservation asks the DHCP server to allocate a chosen address to a particular client binding.

The client still uses DHCP

Address arrangement Where the address choice is maintained
Ordinary dynamic allocation DHCP server’s pool and lease policy
Reservation DHCP server’s client-to-address binding
Manual static configuration The client/interface configuration

With a reservation, the client can still obtain its address and other options through the DHCP exchange. This differs from typing the address, prefix, router and DNS settings into the client manually.

The DHCP server needs a consistent allocation policy so the reserved value is not also handed to another client.

Emby’s connectivity documentation points to a DHCP reservation as a way to stabilize the server’s local address.

The binding belongs to a client identity

This original reduced allocation model uses explicit client keys:

{
  "reservations": {"client-A": "192.168.50.20"},
  "requestClient": "client-B",
  "reservedMatch": false,
  "dynamicOffer": "192.168.50.42"
}

Client B does not match client A’s reservation. Keeping the computer’s display name unchanged does not alter that comparison.

A DHCP server can identify clients through client identifiers and/or hardware-address-related bindings according to its implementation. A router’s user interface may expose a MAC-based reservation.

Replacing the adapter, changing its exposed identity or using another interface can therefore need a different binding. “This is the same computer” is not necessarily the identity the DHCP server compares.

A stable choice still has a lease lifecycle

For an original twenty-four-hour lease using the usual default fractions, renewal begins around hour twelve and rebinding around hour twenty-one if renewal has not succeeded. The lease expires at twenty-four.

Successful renewal extends the binding’s valid lifetime. A client cannot keep using an expired allocation indefinitely merely because a reservation exists in a configuration screen.

The timer details and actual allocation behavior belong to the DHCP implementation. The reservation supplies a preferred stable choice within that process.

Stabilize the references that use the address

A port-forward rule targets the internal address. A DNS record or discovery advertisement can report it. A cached app entry can retain it.

Changing the binding does not automatically rewrite every separate reference or immediately move an already leased client to the new value.

See Also

References