DHCP | IoT Worker

DHCP

Reading time: 13 minute Word count: 2645
Network DHCP IP UDP

When a new device plugs into the network, it usually does not know which IP address to use, who the gateway and DNS servers are, or whether the network is willing to hand out an address for a long time. The network, on the other hand, wants it online quickly, ideally without manual configuration, while still keeping control over address assignment, reclamation, and policy changes.

DHCP exists to handle exactly that. It looks like “automatic IP assignment,” but the real job is initial control-plane allocation: let the terminal join with almost no preconfiguration, while the network keeps the power to push parameters, reclaim addresses, and adjust policy later.

This article focuses on DHCPv4. The goal is to understand why DHCP appeared, why it became “broadcast discovery + lease + renewal,” and what the most useful checkpoints are when you implement a client, capture packets, or debug a deployment. DHCPv6, PXE, failover, and vendor-specific options are out of scope.

DHCP keeps control of network parameters on the network side with leases, while still allowing terminals to join with almost zero preconfiguration

Main Model

DHCP is shaped by three constraints:

The terminal does not know who it is -> it must broadcast first and ask the network
The network does not know whom it should trust forever -> it can only lease an address temporarily
The network changes over time -> leases must be renewable, rebindable, and reclaimable

From those constraints, the article keeps coming back to three actors and one central mechanism:

  • Client: wants to join the network but initially knows almost nothing
  • Server: owns the address pool and the network parameters
  • Relay: extends the control plane across broadcast boundaries
  • Lease: the address is not ownership, but a time-limited right to use it

So DHCP is not just Discover -> Offer -> Request -> ACK. What it really maintains are three judgments:

  • A terminal should not be expected to preconfigure itself before first access
  • Network parameters include more than the IP address
  • Those parameters cannot be hard-coded forever because topology, policy, and location all change

Problem Background

What Was the Problem Before DHCP

In early LAN environments, the problem was simple: every terminal needed an IP address, subnet mask, default gateway, and often DNS. None of those parameters were naturally known by the terminal, and users did not want to configure them manually at scale.

The problem with static configuration was never just that it was annoying. Once the number of machines grew, the system-level cost became obvious:

  • Address conflicts became common, especially with mobile devices, replacements, and bulk deployment
  • Network parameter changes were expensive, because gateway, DNS, or subnet changes affected every terminal
  • Control stayed on the client side, while the network side had little ability to manage or reclaim resources centrally

You can survive with static configuration on a few fixed devices. You cannot scale that approach to office networks, campus networks, enterprise networks, or today’s large IoT fleets.

BOOTP Solved Part of It, But Not Enough

DHCP did not appear from nowhere. It inherited directly from BOOTP. BOOTP already answered an important question: when a terminal does not yet have a full network configuration, how can it broadcast to the network and get what it needs to boot?

But BOOTP was closer to “static mapping delivered automatically.” It fit relatively fixed device sets, not frequent up/down churn, address pool reuse, or dynamic parameter updates.

DHCP did not simply add “automatic configuration.” It moved automatic configuration from a static table model to a lease-driven model. Addresses stopped being almost permanent configuration entries and became dynamic resources that can be assigned, renewed, and reclaimed.

Its IETF Origin Shaped the Protocol

DHCP comes from the IETF family, with RFC 2131 and RFC 2132 as its core specifications. It was never written for one vendor’s private network. It was written for interoperability across heterogeneous hosts, operating systems, and network devices.

That gives it a few strong design tendencies:

  • Compatibility comes before architectural elegance
  • Existing infrastructure should evolve rather than be replaced wholesale
  • The protocol must survive on real networks with uneven implementations

That is why DHCP contains a lot of design choices that do not look perfectly clean. The point was never that the designers missed a prettier approach. The point was that DHCP had to survive in the IP networks of its time.

What DHCP Actually Solves

It Solves More Than an IP Address

What the client receives is not just an address. It gets a full set of network entry parameters and a time-limited right to use them.

yiaddr (your IP address, the address assigned by the server) is the most visible field, but DHCP can also hand out:

  • IP address
  • Subnet mask
  • Default gateway
  • DNS server
  • Lease time
  • Explicit renewal and rebinding times, or values derived from the lease
  • Other policy-related options

So DHCP is a control-plane protocol for network access, and the address is just the part people notice first.

It Balances Network Side and Terminal Side Interests

DHCP is not a one-sided optimization.

The terminal wants:

  • Almost zero configuration
  • Usable parameters quickly
  • Automatic recovery after disconnection

The network wants:

  • Address resources that can be reclaimed and reused
  • Centralized parameter changes
  • Access that is manageable, auditable, and scalable

The lease is the compromise between those two needs. The terminal gets a network identity that works now. The network keeps the right to change or reclaim it later.

The Most Common Successful Path

  1. The client has no address and does not know where the server is, so it broadcasts Discover.
  2. One or more servers reply with Offer, each proposing an address and a parameter set.
  3. The client selects one proposal and sends Request to accept it explicitly.
  4. The chosen server replies with ACK, the lease becomes valid, and the client applies the address and related parameters to the stack.
  5. The lease enters its maintenance phase. At T1, the client tries to renew with the original server. After T2, if that still fails, it falls back to rebinding through broadcast.

Two parts of that chain are easy to misread:

  • ACK does not mean “the process is over.” It means “the configuration is now ready to take effect.” The client still has to apply the address, routing, DNS, and related parameters.
  • Renewal is not a side detail. It is part of the DHCP model. Without renewal and expiration, the lease becomes static configuration with a different name.

Why These Mechanisms Exist

Broadcast Was the Only Real Start

At startup, the DHCP client usually does not know three things:

  • Which IP it should use
  • Which DHCP server exists
  • Whether the server is on the same subnet

Under those conditions, unicast to a known server is not realistic. Broadcast is not elegant, but it is the cheapest available bootstrapping method.

Discover does not really mean “I am looking for an address.” It means “I am looking for a control point that can define my network identity.”

Broadcast also has obvious costs:

  • It is limited by the broadcast domain
  • Large networks need relays
  • The initial path becomes sensitive to layer-2 and relay configuration

Broadcast is not the ideal design. It is the lowest-cost design when the startup phase has too little information.

Offer -> Request Separates Candidate from Commitment

Offer and Request insert an important distinction: the server cannot just declare the result final.

At that point, the server does not yet know whether the client will accept the address, and the client may receive several offers at once. Without a “propose first, confirm later” handshake, the server would not know whether an address is merely a candidate or already committed.

The client typically waits for a short time and then chooses one acceptable offer. The protocol does not mandate a single selection algorithm; common implementations prefer the first usable offer, a previously used server, or the one that best matches local policy. Once the choice is made, the client must include the corresponding server identifier in Request.

Offer -> Request does three things:

  • The server says, “I am willing to give you this address”
  • The client explicitly chooses one candidate
  • Other servers see the Request and know their proposals were not accepted

That separates resource intent from resource commitment. It adds one round-trip, but the coordination boundary becomes much clearer.

The Address Must Be a Lease, Not a Permanent Configuration

This is the core DHCP decision.

If an address were permanently assigned the first time, the network side would soon face three problems:

  • The pool would be occupied by long-gone devices
  • Parameter changes could not propagate naturally
  • The network would lose the ability to reclaim control over time

The value of a lease is not just that it can be reclaimed. It turns access state into soft state. Soft state means:

  • The two sides do not need to stay perfectly synchronized forever
  • State can expire naturally
  • If one side disappears temporarily, the system can recover through retry, renewal, or rebuild

That is a very typical Internet design pattern. It gives up some short-term certainty in exchange for better long-term recoverability.

Renewal Uses Unicast First, Rebinding Falls Back to Broadcast

This design shows the tradeoff between efficiency and robustness very clearly.

When the client already knows the original server, renewing by unicast is cheaper:

  • Smaller packet scope
  • No need to involve the whole broadcast domain
  • Clearer semantics: “continue an existing relationship”

T1 and T2 are the two key lease times. T1 is when the client first tries to renew with the original server. T2 is when, if that still fails, it falls back to rebinding by broadcast. They are usually derived from the lease time; the common defaults are T1 = 0.5 * lease and T2 = 0.875 * lease.

If the original server is unreachable, the client cannot stay tied to it. After T2, rebinding must use broadcast so that any available server can take over.

That switch changes the assumption:

  • In the normal case, assume the original control point is still alive and renew cheaply
  • In the failure case, drop that assumption and ask who else can define my identity

The complexity in DHCP is not feature bloat. It is failure-path recovery.

Many Capabilities Live in Options

Many DHCP parameters are carried in options rather than fixed header fields. The core header stays stable, while extensible semantics live in options.

That gives you:

  • Older implementations can ignore options they do not understand
  • New capabilities can be added incrementally
  • Different networks can deliver different policies

The tradeoff is also clear:

  • Implementations vary widely in quality
  • Clients often support only part of the option space
  • Field failures often look like “the address is there, but the policy never really took effect”

Options improve evolution, but they also move complexity into interoperability.

The Less Elegant but Important Design Choices

DHCP Manages Time, Not Just Addresses

When people look at DHCP, they often focus only on the pool. From the protocol’s point of view, though, it is really managing time.

When the address becomes valid, when it should be renewed, when it should be rebound, and when it expires all determine whether the network state can remain basically consistent without tight synchronization.

That is also why timer quality is often more important than field parsing when implementing a DHCP client. A parsing bug usually shows up quickly. A timer or state-machine bug may only show up after days of runtime, a few link changes, or one short server outage.

State Is Not Centralized in One Place

The server knows what it has leased out. The client knows what it currently believes. The two sides are not guaranteed to stay identical forever, and they converge through messages and timeouts.

This distributed-state design has clear advantages:

  • The system does not depend on a permanent connection
  • A short failure does not immediately break everything
  • It scales better for large terminal fleets

The cost is just as clear:

  • Implementation and debugging must accept intermediate states
  • The client and server can disagree about the same address for a while
  • Recovery paths deserve as much care as success paths

So when you look at DHCP, do not only study the success path. Study the convergence path too.

DHCP Accepts That Real Networks Are Messy

Its assumptions are realistic:

  • Broadcasts may be restricted
  • The server may not be on the local subnet
  • The terminal may suddenly lose power or unplug
  • Multiple servers may exist in the same network
  • Different vendors may implement options, timers, and retries differently

So DHCP’s temperament is not “work as beautifully as possible in an ideal network.” It is “keep working in a messy real network most of the time, and still leave recovery paths when things go wrong.”

How It Evolved Later

DHCP evolved by incrementally extending what real deployments needed:

  • More options for richer network configuration and policy
  • Relay-related extensions to carry the control plane across subnets
  • Different compatibility habits across operating systems and network devices

DHCP is now deeply embedded in existing IPv4 networks and terminal stacks. Even imperfect choices are hard to replace because the deployment base is so large. Many details that still affect implementations and field issues today are simply the result of historical compatibility.

How to Use This Understanding in Engineering

What to Lock Down First in a Client

For a minimal useful implementation, prioritize:

  • Making Discover -> Offer -> Request -> ACK work end to end
  • Applying address, mask, gateway, and DNS correctly to the stack
  • Maintaining lease / T1 / T2 correctly
  • Handling NAK, timeout, link loss, and renewal failure

Many implementations spend too much early effort on option coverage, but then the main state machine and recovery logic remain fragile. For most devices, it is more valuable to make first lease acquisition and lease recovery stable than to support more options.

What to Look At in a Capture

Do not start by staring at every field. Check these decisions first:

  • Did the flow reach ACK
  • Did the system really apply the configuration after ACK
  • Was renewal using unicast, or had it already fallen back to broadcast
  • Is the problem “no parameters were received,” or “the wrong parameters were received”

When analyzing DHCP, first decide whether the issue is in:

  • Discovery
  • Negotiation
  • Configuration application
  • Lease maintenance

The Most Common Failure Paths in Production

The most frequent failures are not “the protocol is completely dead.” They are failures in the middle:

  • Only Discover is visible, but no Offer
  • Offer arrives, but the client never sends Request
  • ACK arrives, but gateway, DNS, or mask is wrong
  • Initial address assignment works, but renewal, rebinding, or recovery fails

The last case is especially dangerous because it can pass basic lab validation. Getting a lease once in the lab does not mean the device can survive a full lease lifecycle in the real world.

If a Device Supports Both Static IP and DHCP

For product design, the worst state is not “DHCP only.” The worst state is “static and DHCP both exist, but the priority and switching rules are unclear.”

At minimum, decide:

  • If static configuration exists, does it fully bypass DHCP?
  • If DHCP fails, does the device fall back to static configuration?
  • Can static gateway/DNS be mixed with DHCP-derived ones?
  • Should a link change trigger a mode re-evaluation?

Without those boundaries, field issues often get misdiagnosed as DHCP problems when the real issue is unclear product networking policy.

What DHCP asks you to remember is how the lease relationship is created, committed, applied, and maintained. In implementation, packet capture, and troubleshooting, identifying the stage first is usually more effective than diving into the field table from the start.

References and Further Reading

Main References

Supplementary Reading

Further Reading