13  DHCP and Address Resolution

networking-core
addr
dhcp
resolution

13.1 Start With How the Device Learns the Network

Most IoT devices do not wake up already knowing their useful network identity. DHCP, ARP, DNS, and neighbor discovery are the support conversations that turn a powered device into a reachable participant.

When a device fails, these conversations are often where the first clue lives. Before blaming the application, prove how the device received an address, found a gateway, translated names, and mapped neighbors on the local link.

Overview: Addressing Has Two Jobs

DHCP gives an IoT device a usable IP configuration. Address resolution then finds the local link-layer destination for the next hop. Both jobs must be healthy before a sensor can reliably reach a gateway, broker, dashboard, or peer device.

The configuration job is more than the address itself. A lease normally carries the subnet mask, default gateway, DNS servers, lease lifetime, renewal behavior, and sometimes site options such as NTP or boot information. If any one of those settings is wrong, the device may look "online" in the DHCP table while still failing application traffic.

The local-delivery job starts after configuration. A device decides whether the destination is local or remote from its address and mask. Local destinations need ARP in IPv4 or Neighbor Discovery in IPv6; remote destinations need resolution for the default gateway. Troubleshooting has to prove both decisions, because a healthy lease can still be paired with a stale neighbor cache, duplicate address, or wrong route boundary.

DHCP DORA process showing a client discovering a server, receiving an offer, requesting the address, and receiving acknowledgement.
The DHCP DORA exchange assigns address settings; it does not by itself prove local frame delivery.

Discover

A new client broadcasts for a DHCP server because it does not yet know its own usable network settings.

Offer

The server proposes an address, subnet mask, gateway, DNS, lease time, and any site-specific options.

Request

The client accepts one offer so all listening servers know which lease is being claimed.

Acknowledge

The server confirms the lease and starts the timer that controls renewal and expiry behavior.

Addressing Contract

A valid IoT addressing design records three things: how devices obtain addresses, how those addresses map to local delivery, and what evidence proves the result. DHCP lease logs, ARP or neighbor tables, gateway routes, and device telemetry should agree.

Question Evidence Common Failure
Did the device receive usable settings? Lease table, client log, address, mask, gateway, DNS, lease time. Wrong pool, exhausted pool, short lease, missing gateway, or stale reservation.
Can it deliver to the next hop? ARP cache for IPv4 or neighbor table for IPv6. IP conflict, stale cache entry, duplicate address, or wrong subnet mask.
Will it survive maintenance? T1/T2 renewal timing, redundancy plan, and outage test. Fixed sensors with one-hour leases losing addresses during a planned DHCP outage.

Practitioner: Match Lease Policy to Device Behavior

DHCP is not just an address dispenser. In IoT networks it is an operations control point: lease duration, reservation policy, static ranges, DNS/NTP options, and pool boundaries determine how devices behave during movement, maintenance, and growth.

Fixed sensors

Use long leases such as 7 to 30 days because the devices rarely move and frequent renewal adds noise without value.

Mobile devices

Use shorter leases such as 1 to 4 hours so addresses return to the pool when phones, tablets, or carts leave.

Critical devices

Use DHCP reservations when gateways, cameras, meters, or controllers need predictable addresses with central management.

Infrastructure

Keep routers, switches, and the DHCP server itself in a documented static range outside dynamic pools.

Device Class Assignment Lease Evidence to Keep
Fixed environmental sensors Dynamic DHCP pool 7 to 30 days Lease table, expected count, pool utilization, renewal success.
Cameras and floor gateways DHCP reservation by MAC address 30 days or longer Reservation record, asset label, monitoring target, gateway reachability.
Commissioning devices Temporary test pool 30 minutes to 1 hour Hostname, owner, expiry time, and removal after test.
Routers and DHCP service Manual static address Not applicable Network diagram, config backup, change record, and route test.

Lease Timing Review

DHCP clients try to renew at T1, normally 50 percent of the lease, and retry more broadly at T2, normally 87.5 percent. A 7-day fixed-sensor lease gives a 3.5-day window before the first normal renewal; a 1-hour lease makes fixed devices depend on the server every 30 minutes.

Smart-Building Example

  • Reserve `192.168.1.1` to `192.168.1.20` for network infrastructure and cameras.
  • Use a dynamic sensor pool such as `192.168.1.50` to `192.168.1.249` with 7-day leases.
  • Keep commissioning laptops or test devices in a separate short-lease range.
  • Record the static range, dynamic pool, reservations, lease policy, and owner in the design record.

Under the Hood: Diagnose ARP, Neighbor Discovery, and Conflicts

Once an IoT device has an IP configuration, it still needs local delivery evidence. IPv4 uses ARP to map a local IP destination to a MAC address. IPv6 uses Neighbor Discovery, Router Advertisements, Duplicate Address Detection, and SLAAC for related jobs.

In IPv4, the route decision happens before ARP. The host compares the destination with its own address and subnet mask; if the destination appears local, the host broadcasts an ARP request for that destination. If the destination is remote, the host sends the frame to the default gateway's MAC address instead. A wrong mask therefore creates misleading symptoms: the device may repeatedly ARP for a remote PLC, server, or broker that should never be resolved on the local segment.

Conflict diagnosis also needs timing evidence. DHCP lease tables show who was assigned an address, but they do not prove that no static device is using the same address. ARP caches, switch MAC tables, gateway logs, and duplicate-address alarms show whether one IP is moving between link-layer identities. IPv6 adds Duplicate Address Detection and neighbor-cache state, so the same investigation checks router advertisements, prefixes, and whether a tentative address became usable.

ARP request and reply process where a sender broadcasts for an IP address and the target replies with its MAC address.
ARP is a local-segment protocol. If the subnet mask is wrong, a device may ARP for a destination that should have gone to the router.

Normal ARP evidence

One local IP maps to one MAC address, and the cache agrees with the DHCP lease or reservation record.

ARP flapping

One IP alternates between two MAC addresses, usually because two devices claim the same address.

Wrong mask

A device thinks a remote subnet is local and ARPs directly instead of sending traffic to its default gateway.

Neighbor cache

IPv6 neighbor tables show link-layer reachability, router information, and duplicate-address behavior.

IPv6 SLAAC process with router discovery, prefix advertisement, address generation, and duplicate address detection.
SLAAC lets IPv6 devices form addresses from advertised prefixes, then check for duplicates before using them.

Conflict Evidence Pattern

  1. Gateway ARP table shows `192.168.10.45` alternating between two MAC addresses.
  2. DHCP leases show Sensor A was assigned `.45` and Sensor B was assigned `.67`.
  3. Sensor B is found with a manually configured static `.45` address.
  4. Fix by returning Sensor B to DHCP, creating a reservation, or moving static addresses outside the dynamic range.

Useful Commands

Use `arp -a` or `ip neigh` for local neighbor evidence. Use DHCP server leases for assignment evidence. Use `ip route get TARGET` to confirm whether a device will send traffic locally or through the gateway.

13.2 Summary

  • DHCP assigns usable IP configuration, including address, subnet mask, gateway, DNS, options, and lease timing.
  • Address resolution is a separate local-delivery step: ARP for IPv4 and Neighbor Discovery for IPv6.
  • Lease duration should match device mobility and maintenance risk, with long leases for fixed sensors and shorter leases for mobile or temporary devices.
  • DHCP reservations give predictable addresses while preserving central management; static infrastructure ranges should stay outside dynamic pools.
  • IP conflicts, stale neighbor entries, and wrong subnet masks leave evidence in lease tables, ARP/neighbor tables, route decisions, and device logs.

13.3 Key Takeaway

Treat DHCP and address resolution as a single evidence chain: prove how the device got its configuration, how it resolves the next hop, and what will reopen the addressing decision when scale, movement, or maintenance conditions change.

13.4 See Also