DHCP: how a device gets an address
Addresses are not handed out by hand: the four DORA messages, the whole settings bundle (address, mask, gateway, DNS), the range and the lease time, reservations by MAC, relays into remote networks – and finally the rogue server, the drained range and the defense on the switch.
Lesson 1: Why addresses are not handed out by hand
Manual addresses and their limits
Every device in a network needs an IP address – without one it has no way to ask for data. In the courses Why networks exist and how data travels and Routing and IP addresses you set addresses by hand, and with three machines that is perfectly fine. But manual addresses hit a hard ceiling. Nobody keeps the register. The addresses live in the admin’s head or in a table that stops matching reality the moment somebody brings in a laptop. Two machines get the same number – and that is a conflict: the machines notice it themselves (they ask who owns the address), but a human has to fix it – the network suddenly does not know whose data is whose, and it fails for both. A visitor has no chance. Whoever comes for a meeting would have to request an address from the admin. And when the gateway or the DNS server changes, you walk around every machine one by one. That is why DHCP exists: a service that lends addresses itself, makes sure none repeats, and packs the rest of the settings in with the address.
Step by step
- With one machine a manual address is the simplest thing in the world: you type a number and you are done. The problem is not the first machine.
- A second machine arrives and somebody mistypes. The same address twice = a conflict, and connections break for both. The nasty part is that it does not look like an addressing mistake, but like “it works sometimes”.
- Now a visitor arrives with a laptop. The manual system has no answer for them – they either bother the admin or guess and cause a conflict.
- DHCP reverses the direction: you do not set the address, you ask for it. One place keeps the register, so one number cannot go to two machines.
What a client actually needs
If DHCP only lent an address, it would be useless. A device needs four pieces of information to actually work in a network. 1) The IP address – its own number, by which the others find it. 2) The subnet mask – from it the device knows who its neighbors are and whom it may send data to directly (how a mask does that is taken apart in the course ISO/OSI and TCP/IP: the network map). 3) The default gateway – the router’s address, where it sends everything that is not a neighbor; without it you reach your own network but no further (exactly the default route from the course Routing and IP addresses, seen from the client’s side). 4) The DNS server – without it addresses work but names do not; the user describes this as “the internet is down” even though technically it is not. So DHCP does not send a number, it sends a whole settings bundle. That is its second, less visible half: when you change the DNS server, you rewrite it in one place and it spreads on its own.
Step by step
- The address alone means only “this is my number”. So far you do not know whom you may talk to.
- The mask lets the client decide who counts as a neighbor. To a neighbor it sends a frame directly through the switch, with no router.
- The gateway is the router’s address. Without it the client moves only inside its own network – it cannot get out, and that looks like an internet outage.
- And the DNS server: without it you reach an address but not a name. The user reports “nothing works” – while the network is running fine (the course DNS and names in the network).
Where the DHCP server lives
Many people picture a “DHCP server” as a special box in the server room. In fact it is a role, not a piece of hardware – and networks of different sizes hand it to different devices. In a home the ISP router does it; that is why everything works by itself at home and you have never heard of DHCP. In a smaller company the role usually sits on the router or the firewall at the network edge, since that box is the gateway anyway. In a larger company DHCP runs on a server or an L3 switch – closer to whoever needs the addresses, and able to manage several networks from one place. The simulator is the same: you switch the DHCP role on in the detail of a router, a firewall, an L3 switch or an ordinary server. What matters is that in one network one device holds this role. Two servers handing out from the same range start stepping on each other – and that is exactly what the last lesson is about.
Step by step
- At home DHCP hides inside the ISP router. That is why your connection just works and you never set anything up.
- In a smaller company the role usually sits on the edge router or firewall – it is everyone’s gateway anyway.
- In a larger company DHCP runs on a server or an L3 switch – one place can serve several networks at once.
- Whoever you give the role to, one rule holds: one DHCP server per network. What two of them do you will see in the last lesson.
Lesson 2: DORA: the four messages
Discover: a shout into the dark
You switch a laptop on. It has no address, no mask, no gateway – it knows nothing at all about the network, not even whether a DHCP server is in it or where to look for one. Yet it has to start somehow. It solves this the only way it can: it shouts into the dark. It sends a DHCP Discover as a broadcast – a frame addressed to “everyone”, which the switch floods across the network (more precisely across that VLAN; from the course Switching and VLANs you know the wall stops it there). Its header carries 0.0.0.0 as the sender, because it has no address yet, and 255.255.255.255 as the destination, meaning “anyone who hears this” (all-ones in an address means “everyone”, all-zeros means “nobody yet” – which is why the sender is 0.0.0.0). It also attaches its MAC address – which it always has, burned into the network card – so that someone can identify it in the reply. (Careful: “burned in” means from the factory, not unchangeable – what a machine writes into the frames it sends is up to the machine, and that is exactly what the attack in the last lesson exploits.) This first step is also why DHCP does not cross a router unaided: a broadcast stops at the network boundary. We will get to that in the fourth lesson.
Step by step
- After power-on the client knows nothing: no address, no gateway, no idea who is in the network.
- It sends a Discover: from 0.0.0.0 (I have no address) to 255.255.255.255 (to anyone). It attaches its MAC so the reply can find it.
- The switch floods the frame to every port of that VLAN. Machines it does not concern hear it too – a property an attacker will later abuse.
- The router does not pass the broadcast – the search ends there. That is why remote networks need the help the fourth lesson is about.
Offer: an offer, not an order
The Discover reaches the DHCP server, which speaks up for the first time with an Offer. This is not an assignment yet; it is “I have this address for you, do you want it?”. The server first picks a free address from its range, and before offering it, sets it aside temporarily so it does not offer the same one to somebody else meanwhile. Into the offer it packs the rest of the bundle from the second module: the mask, the gateway, DNS and how long the address is lent for. It replies to the client’s MAC address, because the client still has no IP. If the client does not answer with a Request within a short window, the server releases the set-aside address again – otherwise it would hold it forever for a machine that has since been switched off. The word offer is not accidental. A network may hold several servers and a client may receive several offers – the decision is the client’s. And this is exactly the property a rogue server exploits when it tries to be faster than the real one.
Step by step
- The server got the Discover and reaches into its range for a free address. It sets the chosen one aside so it will not offer it twice.
- It sends the Offer. It replies to the client’s MAC – the client still has no IP address, so there would be no other way to address it.
- The offer is not just a number – it holds the whole bundle from the second module, including how long the address is lent for.
- It is an offer, not an order. Anyone can offer – including a rogue server trying to be first. The fifth lesson shows what follows from that.
Request and Acknowledge
The client picks one of the offers – usually the one that arrived first – and answers with a Request. The odd part is that this also goes as a broadcast, even though the client now knows whom it is talking to. There is a good reason: this way the other DHCP servers learn of the decision too and can release their set-aside offers back into the range. If the Request went only to the chosen server, the others would hold addresses for nothing. The server then confirms with an Acknowledge, and only at that moment is the address truly leased: it is written into the lease table with a time and the client’s MAC address. The four messages together – Discover, Offer, Request, Acknowledge – are shortened by their initials to DORA. If you remember one thing, make it this: the first two messages are asking and offering, the second two are choosing and confirming.
Step by step
- The client picks an offer and sends a Request. As a broadcast again, even though it already knows whom it chose.
- That is why it is a broadcast: the other servers learn they were not chosen and return their set-aside address to the range.
- The Acknowledge is the moment the address is genuinely leased. The server writes it into the table with a time and the MAC address.
- Four messages = DORA. The first two are asking and offering, the second two choosing and confirming.
When two answer
Let us pause on one sentence from the third module, because it matters more than it looks: the client usually picks the offer that arrived first. Not the best one, not the one from the right server – simply the fastest. DHCP has no authentication whatsoever. The client has no way to tell whether the answer came from the company server or from the laptop of somebody playing around in the network. It knows no password, checks no signature, holds no list of permitted servers. It trusts whoever was quicker. Two things follow. First: having two DHCP servers in one network by accident (say when somebody brings a home router and plugs it into a socket) disrupts the network in a way that is surprisingly hard to track down – some machines get addresses from somewhere other than the rest. Second: an attacker can do it deliberately, and because the offer also carries the gateway and DNS, they can write themselves in as the way out. The fifth lesson takes both apart.
Step by step
- The client shouts a Discover. Nothing new so far – except that everyone in the network hears this broadcast.
- The real server is further away – across a router and a switch. Its offer is correct, but it takes longer to arrive.
- The rogue is closer, so its offer arrives sooner. And the first offer wins.
- The client has no way to verify the sender. It trusts speed – and the offer also carries the gateway and DNS.
Lesson 3: Range, lease and reservations
The range: from where to where
The range – also called a pool or a scope, you will meet all three words – is the main thing you configure on a DHCP server: from which address to which it may lend. It sounds like a trivial field, but it decides two things at once. How many devices the network can carry – a range from .100 to .150 feeds fifty clients, and the fifty-first is out of luck no matter how large the subnet is. And what is left for addresses that must not be lent: the router, servers, printers. That is why a range almost never spans the whole subnet. A typical design leaves the lower part manual (say .1 to .99 for infrastructure) and gives clients the upper part (.100 to .200). The rest stays as reserve. In the simulator you find the range in the network settings – separately for each network, because each subnet has its own addresses and its own boundaries. And beware: a range that is too small does not show up right away. It shows up on the day more people arrive than usual.
Step by step
- The range says from where to where the server may lend. Here a hundred addresses for clients.
- The lower part of the subnet stays manual: router, servers, printers. Those addresses must not be lent to anyone else.
- Clients get addresses from the upper part. Infrastructure and clients then stay out of each other’s way.
- A small range does not show today, but on the day more people arrive. Then the machines are not asking wrongly – there is simply nothing left.
What does not belong in a range
Three kinds of address do not belong in a range, each for a different reason. 1) Addresses somebody already holds manually. The router, the DNS server, the printer, the cameras – everything you set fixed. If the server lent them out, you would get exactly the conflict from the first lesson, only this time caused by DHCP itself. 2) The network and broadcast addresses. The first and last address of every subnet carry a special meaning – the first names the whole subnet, the last means “everyone in here at once” (the course Splitting a network: subnets in practice takes this apart) – and must not be assigned to a client – so the server skips them by itself. 3) Addresses you keep in reserve. Next time you add a server, you will appreciate having somewhere to put it. The practical rule reads: whatever has a fixed address should lie outside the range. The alternative is a reservation, the subject of this lesson’s last module – it leaves the address inside the range but ties it to one specific device. Both are correct; the worse third option is a fixed address in the middle of the range that the DHCP server knows nothing about.
Step by step
- Whatever has a fixed address should lie outside the range. Otherwise the server will lend it to somebody else one day.
- The network address and the broadcast address carry a special meaning. The server skips them itself and never assigns them to a client.
- The worst case: a fixed address in the middle of the range that the server does not know about. One day it lends it and you have a conflict.
- With a clean range DHCP does exactly what it should – and the address conflicts from the first lesson disappear entirely.
The lease: lent for a time
An address is not given, it is lent – for a time called a lease. Along with the address the client receives the information on how long it holds; typically hours to days. Why on a timer at all? If addresses were lent permanently, the range would gradually fill with machines nobody has powered on for ages – a visitor who spent an hour here once would hold an address forever. The lease solves this by itself: whatever is not renewed falls back into the range. Meanwhile the client does not lose its address mid-work. At roughly half the time it quietly asks for an extension and the server usually grants it – which is why you never notice renewals. The lease length is a design decision: in an office with the same people every day a long one fits (less traffic, more stable addresses). At an airport or a café a short one instead, because people come and go quickly and addresses have to come back.
Step by step
- With the address comes the time it holds for. It is not a gift, it is a loan.
- At roughly half the time the client quietly asks for an extension. That is why you never lose the address mid-work.
- Whoever stays silent loses the address and it falls back into the range. That is how the pool cleans itself.
- You choose the length by the traffic: long where the same people stay, short where they come and go quickly.
Reservations by MAC
Sometimes you want both at once: for a device to get its address automatically from DHCP, but always the same one. Typically a printer, a camera, a NAS or a server that somebody refers to by a fixed address. The solution is a reservation: on the server you say “the device with this MAC address always gets this IP”. The client notices nothing – it asks for an address through DORA as usual and receives it as usual, only it is the same one every time. Why the MAC? Because it is the one thing the client holds even before it has an address, as you know from the Discover. Compared to manual configuration a reservation has one large advantage: the settings stay in one place. When you change the gateway or DNS, the printer gets it too – whereas a machine with a hand-set address would stay behind with the old one, and one day you would wonder why that particular machine is the one that fails.
Step by step
- A printer behaves like any other client – except people and systems refer to it by a fixed address.
- On the server you create a reservation: this MAC address always gets this IP.
- The client asks for the address entirely normally through DORA. It just happens to come out the same every time.
- The advantage over a manual address: the settings stay in one place, so a gateway or DNS change reaches here too.
Lesson 4: When the server is elsewhere: the relay
A broadcast does not cross a router
Let us return to where the second lesson ended. The client looks for a server with a broadcast – and a broadcast stops at the network boundary, because the router does not pass it on. That is neither a bug nor an oversight; it is exactly why routers exist. If broadcasts crossed, the whole internet would be one giant network where everyone hears everyone. But it means a client in a branch office will never hear the DHCP server at headquarters. However powerful the server, however good the link – the Discover simply does not reach it. Three solutions offer themselves. A DHCP server in every network – it works, but it means managing ranges in ten places instead of one. Manual addresses in the branch – that is a step back into the first lesson. Or a relay: let somebody who is in both networks carry the message across. That is the next module’s subject.
Step by step
- In the branch a machine with no address powers on. It behaves exactly as at headquarters: it shouts a Discover.
- The Discover reaches the router, which is in the branch network too. And there it ends.
- The router does not forward the broadcast – and rightly so. If it did, the internet would be one giant network.
- The server at headquarters never learns of the client. No amount of performance or link speed helps – the message does not arrive.
The relay: repackage and forward
A DHCP relay (sometimes a relay agent) is a router function that solves this problem with a simple trick. The router is in the branch network – it hears the broadcast. With the relay switched on it does not drop it but repackages it: it turns it into an ordinary addressed packet sent straight to the DHCP server’s address, which you enter manually when you turn the relay on. And since it is no longer a broadcast, it crosses the whole network to headquarters without trouble. The trick has a second half, without which it would not work: the relay adds which network the client came from. That way the server knows which range to lend from – otherwise it would hold ten ranges and have no idea which to use. The answer then travels back the same way to the relay, which delivers it to the client. In the simulator you switch the relay on at the router and enter the server’s address; the branch client then gets an address exactly like the one at headquarters.
Step by step
- The client shouts as always and the router hears it – it is in the branch network after all.
- With the relay on, the router does not drop it but repackages it into an ordinary packet aimed straight at the server.
- It also adds which network the client came from – otherwise the server would not know which range to lend from.
- The answer returns the same way and the relay delivers it to the client, which knows nothing of the trick.
One server for several networks
A relay pays off for what it enables: one DHCP server for the whole company. In one place you keep ranges for every network, one view of the leases, one place where you change the DNS server or the gateway. If instead you had DHCP in each network separately, you face ten places to manage and with them ten opportunities for something to drift apart. There is another side to it. When the central server fails, nobody gets an address – whereas with a server in each network the outage would hit only one. So a design usually does not stake everything on one card: either DHCP is doubled (two servers, each lending from a different half of the range), or at least its availability is watched. It is the same reasoning as for DNS in the course DNS and names in the network and the same as for resilience in general: centralizing saves work but concentrates the risk into one point. Nothing is free, you only choose which outcome is worse for your network.
Step by step
- The server holds the range for headquarters and serves it directly, unaided.
- And through the relay it holds the branch range too. One place, one overview, one DNS change for everyone.
- But when this server fails, nobody gets an address – neither headquarters nor the branch.
- That is why DHCP gets doubled: two servers, each lending from a different half of the range. The same reasoning as for DNS.
Lesson 5: When DHCP misbehaves
A rogue DHCP server
The second lesson leads to an unpleasant conclusion: the client trusts the first offer and has no way to verify who sent it. So it suffices to get your own DHCP server into the network, be closer than the real one – and clients will take your settings themselves. Most often this is not an attack. Somebody brings a home router, plugs it into a socket to get more ports, and does not notice that the box hands out addresses too. The result looks like a mystery: for some machines the network works, for others it does not, and it depends on which server happened to be faster. The deliberate variant is nastier. The offer also carries the gateway and DNS – so an attacker needs to break nothing, it is enough to write themselves in as the way out. From that moment all the victims’ traffic flows through their machine, and they can read or change it. It is one of the cheapest routes into the middle of somebody else’s communication, and it needs no vulnerability at all – just a socket.
Step by step
- A rogue DHCP appears in the network. Usually not by attack – a home router plugged in “for the ports” is enough.
- The Discover is a broadcast, so both servers hear it. Both may offer.
- The closer server is faster and the client takes the first offer. Distance wins, not authorization.
- The offer also carried the gateway. From now on the victim’s traffic flows through the attacker, who can read it.
Starvation: a drained range
The second attack goes at it the other way round: it does not try to answer, it tries to exhaust. The attacker sends Discover after Discover, each with a different made-up MAC address, and the server honestly answers each with an offer and sets that address aside. Before long the whole range is parceled out among machines that do not exist at all. This is called DHCP starvation. To users it looks innocent: a new device simply does not connect, while the others carry on because they already have addresses. That is why it gets blamed on a cable or on Wi-Fi so easily. You recognize it by the server reporting a full range while that many devices are not physically present. The sequel is nasty too: once the range runs dry the attacker can step in with their own server from the previous module – and since the real one has nothing left to offer, there is nobody to compete with. Two attacks that merely annoy on their own take over the network together.
Step by step
- The attacker sends Discover after Discover, each with a different made-up MAC address.
- The server has no reason to doubt – it answers every Discover with an offer and sets that address aside.
- Before long the range is full – parceled out among machines that are not in the network at all.
- A new device does not connect while the others carry on. That is why it gets blamed on a cable – and why it takes so long to find.
Defense: snooping and port security
Both share one cause: the switch does not distinguish which port something arrived on, and treats everything alike. So the defense sits exactly there – on the switch, and you know it from the course The switch in depth. DHCP snooping splits ports into trusted and untrusted. Trusted is the one that genuinely has a DHCP server behind it, or the path to one; all the others are untrusted and the switch simply discards offers from them. The rogue server can offer whatever it likes – it reaches no client. Against range exhaustion, port security from the same course helps: it limits how many different MAC addresses may live behind one port. An attacker wanting to cycle through hundreds hits the wall at the first few. That leaves the operational half: paying attention. A range filling faster than usual, or a device that got its gateway from somewhere other than the rest – those are exactly the traces that logs are collected for (the course Monitoring, logging and detection).
Step by step
- DHCP snooping marks the port that genuinely has a server behind it (or the path to one) as trusted.
- From untrusted ports the switch discards offers. The rogue may offer; it reaches no client.
- Against range exhaustion port security helps: it limits MAC addresses behind a port, so hundreds of made-up ones do not pass.
- And the operational half: pay attention. A fast-filling range or a machine with a foreign gateway are exactly the traces from the course Monitoring, logging and detection.