DHCP (Dynamic Host Configuration Protocol) is a network protocol that automatically assigns IP addresses and related configuration parameters (subnet mask, default gateway, DNS server addresses, lease duration) to devices joining a network. It follows a client-server model defined in RFC 2131 (for IPv4), with related specifications covering options and later updates, reducing the need for static manual address assignment in networks where dynamic configuration is practical.
In practice
In embedded systems, DHCP is relevant whenever a device includes an Ethernet or Wi-Fi interface and needs to operate on an IP network without a pre-configured static address. Microcontrollers with integrated MAC/PHY peripherals, such as the STM32H7 series, ESP32, or W5500-based designs, typically rely on a DHCP client stack running on the MCU or offloaded to a network co-processor. Lightweight TCP/IP stacks like lwIP and uIP include DHCP client implementations that are commonly used in bare-metal and RTOS-based projects.
The initial lease acquisition follows four steps often abbreviated DORA: Discover (client broadcasts a request), Offer (server proposes an address), Request (client accepts the offer), and Acknowledge (server confirms the lease). In practice, real deployments may also involve retransmissions and additional messages beyond this basic flow. Embedded clients must handle lease renewal before expiry, which requires a persistent timer and re-entry into the DORA flow or a unicast renewal request. Forgetting to implement renewal is a common oversight that causes devices to silently lose network connectivity after the lease duration elapses, which may be as short as one hour on some routers.
A practical concern for embedded deployments is the lack of a DHCP server in isolated or industrial networks. In those cases the device must fall back gracefully, either by using a pre-configured static address, a link-local address via Auto-IP (RFC 3927), or by surfacing an error to the application. Hard-coding a dependency on DHCP with no fallback is a common source of field failures. Additionally, DHCP responses can arrive with variable delay, so embedded code should treat the IP stack as not ready until the lease is confirmed rather than assuming an address is available immediately after link-up.
Resource constraints matter when selecting or writing a DHCP client. For DHCPv4, the protocol uses UDP on ports 67 (server) and 68 (client) and requires handling variable-length options fields; DHCPv6 uses a different port scheme and message flow. On memory-constrained MCUs, parsing the full options space or supporting vendor-specific options may need to be trimmed. lwIP's DHCP module is a well-understood reference point: it compiles to a few kilobytes and is a practical starting point for Cortex-M class devices running FreeRTOS or bare-metal loops.
Frequently asked
Do I need DHCP in an embedded product, or can I just use a static IP?
Either approach works. Static addressing is simpler to implement, eliminates the DORA handshake delay at boot, and removes the dependency on a DHCP server. It is common in closed industrial networks or point-to-point links. DHCP is preferable when the device must plug into arbitrary networks (enterprise LAN, home router, test bench) without manual reconfiguration. Many production designs support both, selecting static or DHCP from a configuration stored in non-volatile memory.
What happens if DHCP fails at startup?
Behavior depends entirely on how the application handles it. A robust client should time out after several retransmissions (RFC 2131 recommends exponential backoff), then either raise an error, fall back to a static address, or attempt Auto-IP (RFC 3927) link-local assignment in the 169.254.x.x range. Silently proceeding with a zeroed or stale IP address will cause hard-to-diagnose connectivity failures, so explicit error handling and user-visible indication (LED, log, display) are important.
How does lease renewal work and why does it matter for embedded devices?
After acquiring a lease, a DHCP client is responsible for renewing it before it expires, typically by sending a unicast DHCPREQUEST to the original server at T1 time (50% of the lease duration by default). If the server does not respond, the client retries with a broadcast at T2 (87.5% of lease duration). Failure to renew means the client loses its IP address. Embedded devices that run continuously for weeks or months must implement renewal correctly; a one-time DORA at boot with no renewal logic will silently drop off the network when the lease expires.
Which embedded TCP/IP stacks include a DHCP client?
lwIP is the most widely used; it includes a DHCP client module and is available for
FreeRTOS, bare-metal, and many vendor SDKs (STM32, ESP-IDF, NXP MCUXpresso). uIP (and its successor Contiki's IP
stack) also includes a minimal DHCP client. Some network co-processors, such as the WIZNET W5500 or Murata Wi-Fi modules, can handle DHCP internally, exposing only the resulting IP configuration to the host
MCU over
SPI or
UART.
Can a single embedded device act as a DHCP server?
Yes, though it is less common. An
MCU running a DHCP server is practical for access-point or gateway roles, for example a Wi-Fi to
Ethernet bridge or a device that creates its own local subnet. lwIP includes a DHCP server component (dhcpd) used in some ESP32 and STM32 access-point designs. The server must maintain a lease table in
RAM or
flash, handle address conflicts, and support concurrent clients, which increases code and memory requirements compared to a client-only implementation.
Differentiators vs similar concepts
DHCP is sometimes confused with DNS: DHCP assigns network configuration (IP address, gateway, DNS server address) to a device; DNS translates hostnames to IP addresses. The two are complementary: DHCP commonly tells the client which DNS server to use, but they are separate protocols on separate ports. DHCP is also distinct from Auto-IP (RFC 3927), which is a fallback mechanism for self-assigning a link-local address (169.254.x.x) without a server, used when no DHCP server is reachable.
