DHCP Over UDP: How IP Assignment Uses UDP (2026)

DHCP, the protocol that hands out IP addresses, actually relies on UDP, the "fire and forget" messaging system, to do its job.

Imagine a new computer booting up. It needs an IP address to talk to anything on the network, but it doesn’t have one yet. How does it ask for one? It can’t use TCP, which requires a pre-established connection and a known IP address. So, it broadcasts a DHCP Discover message on UDP port 67 to the entire local network. This UDP packet is like a message in a bottle, tossed into the network sea, hoping a DHCP server will find it.

Here’s a simplified DHCP transaction:

Client (New Machine): Sends a DHCPDISCOVER broadcast on UDP port 67.
```
# Example packet (simplified representation)
UDP: src=0.0.0.0:68, dst=255.255.255.255:67
DHCP: op=BOOTREQUEST, chaddr=00:11:22:33:44:55, ...
```
The src=0.0.0.0:68 is key – the client doesn’t have an IP, so it uses its own hardware address and a source port. The destination 255.255.255.255:67 means "everybody on the local network, listen up on port 67!"
DHCP Server (e.g., 192.168.1.1): Receives the broadcast and sends a DHCPOFFER back to the client, again using UDP. The server picks an available IP from its pool (e.g., 192.168.1.100) and offers it.
```
# Example packet (simplified representation)
UDP: src=192.168.1.1:67, dst=255.255.255.255:68
DHCP: op=BOOTREPLY, yiaddr=192.168.1.100, ...
```
The server usually broadcasts this reply too, because the client still doesn’t have a stable IP to receive directed traffic. yiaddr is the "your IP address" the server is offering.
Client: Receives the offer and sends a DHCPREQUEST to the server, indicating which offer it’s accepting. This is also broadcast.
```
# Example packet (simplified representation)
UDP: src=0.0.0.0:68, dst=255.255.255.255:67
DHCP: op=BOOTREQUEST, chaddr=00:11:22:33:44:55, ciaddr=192.168.1.100, ...
```
ciaddr is the "client IP address" it’s requesting.
DHCP Server: Receives the request and sends a DHCPACK (acknowledgment) to the client, confirming the IP address assignment and providing other network configuration details (subnet mask, gateway, DNS servers).
```
# Example packet (simplified representation)
UDP: src=192.168.1.1:67, dst=192.168.1.100:68
DHCP: op=BOOTREPLY, yiaddr=192.168.1.100, ...
```
Now, the destination can be the client’s newly assigned IP because the client has an IP and can receive directed UDP traffic on its assigned port (usually 68).

The magic of DHCP over UDP lies in its ability to work without a prior connection. When a device joins a network, it has no IP address to speak of, making TCP impossible. UDP’s connectionless nature allows for these initial broadcasts (DHCPDISCOVER) and subsequent replies (DHCPOFFER, DHCPACK) to traverse the network without needing a destination IP address upfront. The client starts with a source IP of 0.0.0.0 and a source port of 68, broadcasting to all devices on port 67. Once an IP is assigned, the communication can become unicast, but the initial bootstrapping relies entirely on UDP’s broadcast capabilities. This is why firewalls need to allow UDP traffic on ports 67 and 68 for DHCP to function.

The most surprising thing about DHCP’s use of UDP is that the DHCPDISCOVER and DHCPREQUEST messages are always broadcast, even if there’s only one DHCP server on the network. The client has no way of knowing which server will respond first, or even if there’s a server available. Broadcasting ensures the message reaches all potential servers simultaneously, and the client then selects the first valid offer it receives.

Here’s how you might see DHCP traffic in action using tcpdump on a client machine that’s just joined a network:

sudo tcpdump -n -i eth0 udp port 67 or udp port 68

When you boot up a new machine or restart its network interface, you’ll see output like this:

10:05:15.123456 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Discover, length 300
10:05:15.567890 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Offer, length 300, xid 0x12345678, secs 5, flags [none]
    Client-IP 0.0.0.0
    Your-IP 192.168.1.100
    Server-IP 192.168.1.1
    Gateway-IP 192.168.1.1
    Subnet-Mask 255.255.255.0
    Lease-Time 86400
    ...
10:05:16.010111 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request, length 300, xid 0x12345678, secs 6, flags [none]
    Client-IP 192.168.1.100
    Server-IP 192.168.1.1
    ...
10:05:16.151615 IP 192.168.1.1.67 > 192.168.1.100.68: BOOTP/DHCP, ACK, length 300, xid 0x12345678, secs 7, flags [none]
    Client-IP 192.168.1.100
    Server-IP 192.168.1.1
    ...

Notice how the client’s IP is 0.0.0.0 for the Discover and Request packets, and the server’s reply (Offer and ACK) is broadcast to 255.255.255.255 until the final ACK is sent to the client’s newly assigned IP. The xid (transaction ID) helps the client match replies to its original request.

DHCP is a stateful protocol, meaning the server keeps track of which IP addresses it has leased to which clients. This state management is crucial for preventing IP address conflicts. The server maintains a database of leases, including the IP address, MAC address of the client, and the lease duration. When a lease expires, the client can renew it, or the IP address can be returned to the pool for reassignment.

The underlying UDP protocol provides a simple, low-overhead way to transport these messages. It doesn’t guarantee delivery, but the DHCP protocol itself has built-in mechanisms for retransmissions and acknowledgments at the application layer. If a DHCPDISCOVER or DHCPREQUEST isn’t answered, the client will eventually retransmit. Similarly, if a DHCPACK isn’t received by the client, it will continue trying to get an IP. This layered approach allows UDP to be efficient while ensuring the critical task of IP assignment is reliable.

The fact that DHCP uses UDP for discovery means that if you have a firewall blocking UDP on port 67 or 68, new devices won’t be able to get an IP address, even if a DHCP server is otherwise functional. This is a common troubleshooting step: ensuring that INPUT and FORWARD chains on firewalls allow UDP traffic between the client’s subnet and the DHCP server’s IP on these specific ports.

The next step after obtaining an IP address is usually learning how that IP address is mapped to human-readable domain names, which involves another UDP-based protocol: DNS.

More Deep Dives in Udp