DHCP
and DORA

In the early days of TCP/IP networking, IP addresses were assigned manually. A network administrator would configure each machine by hand — deciding which address to allocate, recording it in a ledger, then typing it into the device's network configuration. On a network of ten machines this was tedious. On a network of a thousand it was a full-time job. On a network where devices came and went — laptops, printers, phones — it was impossible.

The first attempt at automation was BOOTP — the Bootstrap Protocol, defined in RFC 951 in 1985. BOOTP allowed a diskless workstation to broadcast a request at boot time and receive an IP address from a server in response. It was simple, stateless, and effective for its era. A client sent a single packet; the server looked up the client's MAC address in a static table and replied with the pre-assigned address. No negotiation, no leases, no dynamic allocation. Every address still had to be manually entered into the server's table — BOOTP removed the need to configure each client individually, but it did not remove the administrator's burden of managing address assignments.

op

DHCP — Dynamic Host Configuration Protocol, RFC 2131, published in 1997 — kept BOOTP's packet format and UDP transport but added the critical missing ingredient: dynamic, lease-based address allocation. Instead of a static table, the server maintained a pool of available addresses. Instead of permanent assignments, it issued leases with expiry times. A device that left the network would eventually surrender its address back to the pool. The administrator's job shrank from managing individual assignments to managing a range and a lease duration.

DHCP's address negotiation follows a four-step sequence. The first letters of each step spell DORA: Discover, Offer, Request, Acknowledge. The symmetry is not accidental — the acronym is a genuine mnemonic baked into how networking is taught. What is less obvious is why four messages are needed when two would seem sufficient.

The reason for four messages instead of two comes down to a scenario the designers anticipated: multiple DHCP servers on the same network. When a client broadcasts a Discover, every server that hears it may reply with an Offer. The client picks the first one it receives, but the servers that lost the race do not know this yet — they have tentatively reserved an address. The client's Request is itself a broadcast, naming the server it chose. Every other server sees this Request, understands it was not selected, and releases the address they had tentatively held. The Acknowledge confirms the commitment. Without the Request step, losing servers would have no way to know their offers were rejected.

DHCP uses UDP — an unreliable, connectionless transport. There is no TCP handshake, no guaranteed delivery, no session state. A DHCP message is a single UDP datagram, and if it is lost, the client simply waits and tries again. The packet structure inherits its shape almost verbatim from BOOTP, with the critical addition of an options field that carries the lease duration, subnet mask, default gateway, DNS servers, and dozens of other parameters.

The

xid

xid

The lease is DHCP's most important design decision. Rather than permanently assigning an address, the server rents it for a fixed duration — typically anywhere from one hour on a busy Wi-Fi network to several days on a stable corporate LAN. The client is responsible for renewing before expiry.

At 50% of the lease lifetime, the client attempts to renew by sending a unicast Request directly to the server that issued the lease — no broadcast required this time, because the client already has a working IP address and knows who to talk to. If the server responds with an Acknowledge, the lease is extended from that moment. If the server does not respond — it may be down, or the address may have been reclaimed — the client tries again at 87.5% of the original lease duration, this time broadcasting a Request to any available server. If no server responds by the time the lease expires, the client must stop using the address immediately, release it, and restart the full DORA sequence from the beginning.

T=0        T=T/2      T=7T/8     T=T (expiry)
|          |          |          |
DORA       RENEW      REBIND     RELEASE
full       unicast    broadcast  stop using
handshake  to server  any server address
          ↓
          if ACK → extend from T/2
          if no response → wait for T=7T/8
                           ↓
                           if ACK → extend from 7T/8
                           if no response → restart DORA at T=T

# Common lease durations:
home router     86400   # 24 hours
enterprise LAN  43200   # 12 hours
public Wi-Fi    3600    # 1 hour (high churn)
data centre     300     # 5 minutes (VM churn)

The Preboot Execution Environment — PXE, pronounced "pixie" — is the most radical extension of DHCP's original purpose. Where DHCP normally equips a running operating system with network access, PXE inverts this: it uses the network to deliver the operating system itself to a machine that has none. A bare metal server with a blank drive, a diskless workstation, a network appliance being provisioned for the first time — all of them can boot entirely over the wire if the infrastructure supports PXE.

The mechanism begins with DORA, but the client — firmware running directly in the network card's ROM, before any operating system loads — includes a vendor class identifier in its Discover packet (DHCP option 60, typically set to

PXEClient

siaddr

file

With a server address and filename in hand, the PXE client opens a TFTP connection — Trivial File Transfer Protocol, the simplest possible file transfer mechanism, running over UDP — and downloads the bootloader. The bootloader runs, may itself request further files over TFTP or HTTP, and eventually hands control to a kernel. The machine boots. The entire process — from power-on to a running OS — can happen in under thirty seconds on a well-provisioned network, and leaves no local storage involved at any stage.

# 1. Client broadcasts DHCP Discover with option 60
DHCPDISCOVER
  chaddr  aa:bb:cc:dd:ee:ff     # NIC MAC address
  option  60 = "PXEClient"       # signals PXE intent
  option  55 = [1, 3, 6, 43, 66, 67]  # parameter request list

# 2. DHCP server replies with address + boot info
DHCPACK
  yiaddr  192.168.1.100        # assigned IP
  siaddr  192.168.1.1          # TFTP server address
  file    "pxelinux.0"          # bootloader path on TFTP
  option  3  = 192.168.1.1      # default gateway
  option  6  = 1.1.1.1          # DNS server
  option  43 = [PXE vendor info] # boot server list, menus
  option  66 = "192.168.1.1"    # TFTP server (explicit)
  option  67 = "pxelinux.0"    # boot filename (explicit)

# 3. Client fetches bootloader via TFTP
TFTP RRQ  192.168.1.1:69  "pxelinux.0"  mode octet

# 4. Bootloader runs, fetches kernel + initrd
TFTP RRQ  192.168.1.1:69  "vmlinuz"     mode octet
TFTP RRQ  192.168.1.1:69  "initrd.img"  mode octet

# 5. Kernel boots. Machine is live with no local disk involved.

DHCP Discover packets are broadcasts. Routers, by design, do not forward broadcasts — they exist precisely to contain them within a subnet. This creates an obvious problem: in any network with more than one subnet, clients on the far side of a router would be unreachable by the DHCP server, and you would need a separate DHCP server on every segment.

The solution is the DHCP relay agent — software running on a router or Layer 3 switch that intercepts DHCP broadcasts on the local segment, rewrites them as unicast packets addressed to a known DHCP server, and forwards them across subnet boundaries. The relay inserts its own IP address into the

giaddr

giaddr

DHCP is sometimes described as infrastructure plumbing — the networking equivalent of the water pipes in a building: invisible, unremarkable, and only noticed when something goes wrong. A DHCP failure is immediately total. Every new device that tries to join the network gets nothing. Existing devices keep their leases until they expire, then begin dropping off one by one. A rogue DHCP server — a device accidentally or maliciously responding to Discover broadcasts with wrong gateway or DNS information — can redirect an entire subnet's traffic in four packets.

The elegance of DORA is that it solved a genuinely hard problem — assigning unique addresses dynamically to unknown devices on an unreliable network — using stateless UDP, a 40-byte fixed header inherited from 1985, and four carefully ordered messages. The client begins with nothing. It cannot even use its own IP address as a source — it has none — so it sends from

0.0.0.0

BOOTP is still in there, underneath. The same

op

chaddr

file