DHCP

DHCP (Dynamic Host Configuration Protocol) is how a device that joins a network gets an IP address, and the other settings it needs to use it, without anyone typing numbers in by hand. Every time your phone joins a Wi-Fi network, this short exchange runs in the background before a single web page loads.

What a device needs before it can talk

An IP address on its own isn't enough. To send traffic anywhere useful, a device needs four things:

• An IP address, so other machines know where to send replies.
• A subnet mask, so it knows which addresses are on its local network and which are somewhere else.
• A default gateway, the router it hands traffic to when the destination isn't local. Without it, the device can reach its neighbours but not the internet.
• DNS servers, so it can turn names like example.com into addresses.

You can set all of these by hand. That's called a static configuration, and it works for a handful of servers. It falls apart on a real network: people mistype addresses, two machines end up with the same one, and a laptop set up for the office stops working the moment it joins the Wi-Fi at home. DHCP moves the job to one place, a DHCP server, which keeps track of which addresses are free and hands them out on request. On a home network, the server is almost always built into your router.

The four-message exchange

The conversation between a new device and the server has four steps, usually remembered as DORA: Discover, Offer, Request, Acknowledge.

Discover

The device has no address yet and doesn't know where the server is, so it can't send a normal message to anyone. Instead it broadcasts: it sends a DHCPDISCOVER to every machine on the local network, from the address 0.0.0.0 to the broadcast address 255.255.255.255. DHCP runs over UDP, with clients on port 68 and servers on port 67.

Offer

Any DHCP server that hears the broadcast picks a free address from its pool (Windows Server calls this a scope) and replies with a DHCPOFFER. The offer carries the address plus the settings above and a lease time: how long the device may keep it.

Request

If more than one server replies, the device picks one offer, usually the first. It then broadcasts a DHCPREQUEST for that address. Broadcasting here is deliberate: it tells every other server that its offer wasn't taken, so they can put their addresses back in the pool.

Acknowledge

The chosen server records the lease and confirms with a DHCPACK. Only now does the device configure its network interface and start talking. If the address has gone in the meantime, the server sends a DHCPNAK instead and the device starts again from Discover.

Here is the whole exchange on a network with two DHCP servers:

Leases, not ownership

A DHCP address is lent, not given. Devices leave networks all the time without saying goodbye, and if every phone that ever visited a café kept its address for good, the pool would run dry within a day. The lease makes addresses come back on their own.

A device doesn't wait for its lease to run out. By default, about halfway through it asks the same server to renew, directly rather than by broadcast, and usually gets the same address back for another full lease. If that server doesn't answer, at about seven-eighths of the lease the device broadcasts a renewal to any server. If the lease expires with no answer at all, it stops using the address and starts again from Discover.

Choosing a lease time is a trade-off:

• Short leases (an hour or two) suit busy guest Wi-Fi, where devices come and go. Addresses return to the pool quickly, at the cost of more renewal traffic.
• Long leases (a day or more) suit an office of desks that rarely change. Addresses stay stable, but a pool that's too small can fill up with devices that left days ago.

A worked example: an office network

Say a small office uses the network 192.168.1.0/24, with its router at 192.168.1.1. Laptops and phones should get addresses from 192.168.1.100 to 192.168.1.200, and the printer should always be at 192.168.1.50, so that everyone's print settings keep working.

The printer's fixed address is a reservation: the server ties an address to the printer's MAC address, the hardware address on its network card, and always hands that address to it. The printer still uses DHCP, so its settings are still managed in one place. Here is that set-up for Kea, the open-source DHCP server from ISC:

{
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": ["eth0"]
    },
    "valid-lifetime": 86400,
    "subnet4": [{
      "id": 1,
      "subnet": "192.168.1.0/24",
      "pools": [{
        "pool": "192.168.1.100 - 192.168.1.200"
      }],
      "option-data": [
        { "name": "routers",
          "data": "192.168.1.1" },
        { "name": "domain-name-servers",
          "data": "192.168.1.1" }
      ],
      "reservations": [{
        "hw-address": "aa:bb:cc:dd:ee:ff",
        "ip-address": "192.168.1.50"
      }]
    }]
  }
}

The valid-lifetime of 86400 seconds is a 24-hour lease. routers is the default gateway, and domain-name-servers is the DNS server list; here the router does both jobs, which is common in small offices. The reserved address sits outside the pool, so it can never be handed to anyone else.

You can see the result from any machine. On Windows, ipconfig /all shows whether DHCP is on, which server answered and when the lease expires, and these two commands give the address back and run DORA again:

ipconfig /release
ipconfig /renew

On a Mac, ipconfig getpacket en0 prints the last DHCP reply your Wi-Fi interface received, with every setting in it.

Crossing networks with relays

Broadcasts stop at routers, so a Discover never leaves its own network. A company with dozens of networks doesn't want a DHCP server on each one. Instead, each router runs a DHCP relay: it catches the broadcast, forwards it as a normal message to a central server, and notes which network it came from so the server picks an address from the right pool. On Cisco equipment this is the ip helper-address setting.

Common mistakes

• Static addresses inside the pool. Someone gives a server a fixed address that the DHCP server also hands out, and two machines end up fighting over it. Keep static addresses outside the pool, or use reservations.
• Two DHCP servers by accident. Plugging a second home router into the first often starts a second DHCP server, handing out different gateways. Devices then work or fail depending on which offer arrived first. The same weakness makes a rogue DHCP server an attack: whoever answers first can point devices at their own gateway and DNS server. Managed switches block this with DHCP snooping, which only lets trusted ports send offers.
• A pool that's too small. Long leases on a busy network fill the pool, and new devices get no address at all.
• Misreading a 169.254 address. An address starting 169.254 means no DHCP server answered, so the device gave itself a link-local address that only works on the local link. Look at the DHCP server or the connection, not at DNS or the website.

DHCP and IPv6

Everything above is DHCP for IPv4. IPv6 devices can usually configure themselves using SLAAC (stateless address autoconfiguration), building an address from information the router advertises. DHCPv6 exists alongside it for networks that want a central record of who has which address, much like DHCP does for IPv4.

Key takeaways

• DHCP gives a device its IP address, subnet mask, gateway and DNS servers automatically, so nobody configures machines by hand.
• The exchange is four messages, Discover, Offer, Request and Acknowledge, and the first is a broadcast because the device has no address yet.
• Addresses are leased, and devices renew about halfway through, so addresses from departed devices return to the pool.
• Reservations give a device a fixed address while keeping its settings managed centrally.
• A 169.254 address means no DHCP server answered.