Core CS · Computer Networks
You need an address to ask for an address
A host that has just joined a network has a MAC address and nothing else. It does not know its own IP address, its mask, its gateway or its DNS server, and it does not know which machine to ask. Four messages fix all of that, and every address written on them is forced by something the client does not yet know.
Step a new host through DORA, with every address on every packet →01 The idea
The two addresses that break the deadlock
Start from what a host actually needs before it can do anything useful on an IP network. It needs four things, not one, and an answer that names only the first loses marks. It needs an IP address of its own. It needs a subnet mask, so it can work out which destinations are on its own link and which have to go through a router. It needs the address of that router, the default gateway. And it needs the address of at least one DNS server, or it can reach machines by number and by nothing else. Type those four into every laptop, phone, printer and access point by hand and the network works, right up until somebody plugs in a device you have never met. A coffee shop or a lecture hall cannot be run that way at all.
So the host has to ask. And that is where the interesting problem starts, because asking means sending an IP packet, and every IP packet carries a source address and a destination address. The host has no source address, because being told one is the whole point of the exercise. It has no destination address either, because nothing has ever told it that a configuration server exists, let alone where it lives. Both fields of the very first packet are unknown at the moment the packet has to be built. That is the bootstrap problem, and everything else in this lesson is a consequence of it.
There are exactly two escapes, and IP provides both. The first is 0.0.0.0, the address that means I do not have one. It is legal in the source field of a packet sent by a host that is still unconfigured, and it is legal nowhere else. The second is 255.255.255.255, the limited broadcast address, which means every host on this link. Because the frame carrying it goes to the link-layer broadcast address ff:ff:ff:ff:ff:ff, every network card on the segment accepts it and passes it up. So the client can reach a server without knowing where the server is, by shouting at everyone.
That solves the outbound half. The return half is solved by something the host has had since it left the factory: its MAC address, the 48-bit identifier burned into the network card. The client writes its MAC into the message, and every reply carries it back along with a random transaction number the client invented. So even when the reply is broadcast to the whole segment, the client can pick out the one that is meant for it. Before it has an IP address, the client's identity is its MAC.
One more design decision is worth taking seriously before the messages themselves, because it explains the shape of everything after: what the server hands out is a lease, not a gift. Addresses are a finite pool. Devices leave a network constantly, and almost none of them announce that they are leaving; a laptop that is closed and carried out of the building tells nobody. If addresses were granted permanently the pool would drain and never refill, and somebody would have to go and clean it up by hand. A lease expires on its own, so the pool heals with no administrator involved. The cost of that is a renewal mechanism, which is where half the exam questions on this topic live.
02 Worked example
One client, two servers, four messages
One scene, and it is the same scene for the rest of the lesson: the console in section 04 runs on it and every number in the cheat sheet is checked against it. The network is 192.168.1.0/24 with mask 255.255.255.0 and a router at 192.168.1.1. There are two DHCP servers on the segment, which is normal practice for redundancy: server A at 192.168.1.10 and server B at 192.168.1.11. A laptop with MAC 3c:22:fb:1a:2b:3c has just linked up and holds nothing else. Read left to right.
Four messages, and the striking thing is how little freedom there is in the addressing. On the DISCOVER, the source is 0.0.0.0 because there is no other value the client is entitled to write, and the destination is 255.255.255.255 because the client does not know that server A exists. On the OFFER, the source is the server's real address, and the destination is the broadcast address again: the client set the broadcast flag, the top bit of the two-byte flags field, to say do not unicast to me, my stack cannot yet accept a packet addressed to an IP address I do not own. The client finds its own reply among the broadcast traffic by matching the xid it invented and its own MAC in chaddr. A client whose stack can accept that unicast leaves the flag clear, and the server then sends the OFFER straight to the offered address and MAC. Both behaviours are legal; the flag is what decides.
Now the highlighted node, because why is the REQUEST broadcast is the follow-up you will get, and there are two reasons rather than one. The first is the same constraint as before: an offer is not a lease. Server A has set 192.168.1.101 aside, but the client does not own it and may not send from it, so the source address is still 0.0.0.0 and a unicast reply could not reach it anyway. The second reason is the one that earns the mark. Server B is also on this segment and is also holding an address aside. When the client broadcasts a REQUEST carrying option 54, the server identifier, set to 192.168.1.10, server B reads it, sees another server's identity, and puts 192.168.1.150 straight back in the pool. Had the REQUEST been unicast to server A, server B would have heard nothing and would have had to sit on that address until a timer expired. The broadcast is the message to the servers that lost.
It is worth being exact about when the address becomes usable, because this is where careless answers appear. Not after the OFFER. An OFFER is a proposal, and a client that has received two of them has not accepted either. The binding is written into the server's lease database when it sends the ACK, and only from that point does the address belong to this client. Even then a careful client does one more check first: it sends an ARP request asking who owns 192.168.1.101, and configures the address only if nothing answers. That guards against an address that somebody typed into a device by hand from inside the server's pool, which the server has no way to know about.
Finally, the two numbers that arrive with the lease and are asked about constantly. The lease here is 86400 seconds, so the timers work out as T1 = 0.5 × 86400 = 43200 s, which is 12 hours, and T2 = 0.875 × 86400 = 75600 s, which is 21 hours. Read those as a schedule for the client. At 12 hours it politely asks the server that issued the lease for an extension, by unicast, because by then it has an address of its own to send from and knows exactly who to ask. At 21 hours, if that has got no answer, it stops being polite and broadcasts to any server that will listen. At 24 hours, if that has also failed, the lease is over and the client must stop using 192.168.1.101 and start again at the DISCOVER. Three chances, and they crowd together toward the end on purpose.
03 Mechanics
The messages, the states and the options they carry
Three tables, in the order the questions come. First the messages with their addressing written out, including the two you send at renewal time, because what is different about a renewal is the follow-up that separates a memorised answer from an understood one. Note that DHCP itself is an application-layer protocol: it runs over UDP like any other application, and the only unusual thing about it is that it runs before its host has an address.
| # | Message | Sender | Source → destination IP | UDP ports | What is inside that matters |
|---|---|---|---|---|---|
| 1 | DISCOVER | client | 0.0.0.0 → 255.255.255.255 | 68 → 67 | Option 53 = 1. chaddr is the client MAC, xid is random, option 55 lists the parameters it would like. |
| 2 | OFFER | server | server IP → 255.255.255.255 | 67 → 68 | Option 53 = 2. yiaddr is the proposed address, plus options 1 mask, 3 router, 6 DNS, 51 lease, 54 server identifier. |
| 3 | REQUEST | client | 0.0.0.0 → 255.255.255.255 | 68 → 67 | Option 53 = 3, option 54 naming the chosen server, option 50 naming the wanted address. ciaddr is still zero. |
| 4 | ACK | server | server IP → 255.255.255.255 | 67 → 68 | Option 53 = 5. The committed binding, the same parameters again, plus options 58 and 59 if T1 and T2 are being set explicitly. |
| Now the client is BOUND. The four above are only ever sent by a client that has no lease. Everything below happens to a client that already has one. | |||||
T1 | REQUEST then ACK | client, then its server | client IP → server IP (unicast) | 68 → 67 | Option 53 = 3, ciaddr filled with the client's address, and options 50 and 54 deliberately absent. That absence is how the server knows this is a renewal. |
T2 | REQUEST then ACK | client, then any server | client IP → 255.255.255.255 | 68 → 67 | The same message, broadcast. The client has given up on its own server and is asking whether anybody at all will extend this lease. |
end | RELEASE, or expiry | client | client IP → server IP (unicast) | 68 → 67 | A RELEASE hands the address back early and is optional. If the lease runs out on its own, the client sends nothing and goes back to the beginning with a DISCOVER. |
Why UDP, and why it could not have been TCP. TCP would give reliability for free, and DHCP has to reinvent it with retransmission timers, so the choice looks wasteful until you try to make it. Opening a TCP connection needs a three-way handshake, a handshake needs segments, and a segment needs a source IP address and a destination IP address. The client has neither. TCP is not merely heavy here, it is unavailable: you cannot connect to a machine whose address you do not know, from an address you do not have. UDP asks for nothing. It is a header, a source port, a destination port and a payload, and it will happily carry a datagram from 0.0.0.0 to a broadcast address. Everything TCP would have given is rebuilt by hand: the client retransmits a DISCOVER after about 4 seconds, then 8, then 16, doubling to a cap of 64, with a second or so of randomisation so that a room full of machines powering up together does not retry in lockstep.
Why two fixed ports, 67 and 68, rather than an ephemeral one. The normal pattern is that a client picks a random high port, the server replies to it, and the reply lands on the socket that sent the request. That pattern fails here in both directions. Nothing has told the client which port a server listens on, so the destination port has to be a constant known in advance: 67, inherited from BOOTP in RFC 951. And the reply cannot go to an ephemeral port either, because it is a link-layer broadcast that every host on the segment receives, and on some machines the software that receives it is not even the software that sent the request, a bootstrap ROM having handed over to an operating system in between. So the client end is nailed down too, at 68. Keeping them separate has a second benefit: a server only ever listens on 67 and only ever sends to 68, so it never has to look at another server's broadcast replies, and a client never sees another client's requests.
Second table, the client's own state machine. An exam question here is nearly always which state is this host in or what moves it out of that state, and the two amber rows are the ones people confuse: one is left by a timer at half the lease, the other by a timer at seven eighths.
| State | You arrive here by | You leave when |
|---|---|---|
| INIT | The interface came up, or the lease expired, or the client released it. No address at all. | You broadcast a DISCOVER. |
| SELECTING | Your DISCOVER is out and you are collecting OFFERs. | You choose one and broadcast a REQUEST naming its server in option 54. |
| REQUESTING | Your REQUEST is out and you are waiting for the commitment. | An ACK arrives, or a NAK arrives and throws you back to INIT. |
| BOUND | The ACK arrived, the address is configured, both timers are running. | T1 fires at half the lease |
| RENEWING | T1 fired. You sent a unicast REQUEST to the server that issued the lease. | an ACK returns you to BOUND, or T2 fires |
| REBINDING | T2 fired at seven eighths. You are broadcasting to any server that will answer. | an ACK, or the lease expires and you go back to INIT |
| INIT-REBOOT | You rebooted and still remember an address you held before. | You broadcast a REQUEST naming that address, skipping DISCOVER entirely. An ACK confirms it; a NAK sends you to INIT. |
Read the difference between the two renewal rows out loud, because it is the most examinable line in the lesson. At T1, half the lease, the client already has an address and already knows which server issued it, so it sends a single unicast REQUEST straight there and gets a single unicast ACK back. Two messages, no DISCOVER, no OFFER, nothing broadcast, and no other server on the segment even learns that it happened. At T2, seven eighths, the polite route has failed, so the client falls back to shouting: the same REQUEST, but broadcast, because the specific server it wanted is evidently not answering and any server holding a record for this address will do. It still sends from its own address, because it still legitimately holds the lease. Only when the lease itself expires does the client lose the address and go all the way back to DORA.
Third table, the options. A DHCP message is a BOOTP message underneath: 236 bytes of fixed fields, then the four-byte magic cookie 99.130.83.99 that marks a message as DHCP rather than plain BOOTP, then a variable list of options. Almost everything DHCP actually delivers is an option, so the option numbers are fair game in a viva.
| Option | Name | Appears in | What it does |
|---|---|---|---|
53 | DHCP message type | every message | The one that makes the message what it is: 1 DISCOVER, 2 OFFER, 3 REQUEST, 4 DECLINE, 5 ACK, 6 NAK, 7 RELEASE, 8 INFORM. |
1 | Subnet mask | OFFER, ACK | Which destinations are on this link and which need the router. |
3 | Router | OFFER, ACK | The default gateway. A list, in order of preference. |
6 | Domain name server | OFFER, ACK | The resolvers the host will use for every name lookup it ever makes. |
50 | Requested IP address | REQUEST, when selecting | Which offered address this REQUEST is accepting. Must not appear in a renewal. |
51 | IP address lease time | OFFER, ACK | The whole lease, in seconds. T1 and T2 are derived from it unless 58 and 59 override them. |
54 | Server identifier | OFFER, ACK, REQUEST when selecting | Which server. This is what tells the losing servers to release the addresses they set aside. |
58 / 59 | Renewal (T1) and rebinding (T2) time | OFFER, ACK | Explicit timer values. Left out, they default to one half and seven eighths of option 51. |
82 | Relay agent information | inserted by a relay | Which physical port and which VLAN the request arrived on, so the server can log or police it. |
255 | End | every message | Marks the end of the options field. Anything after it is padding. |
The relay agent, for when the server is not on the segment. A limited broadcast to 255.255.255.255 dies at the first router, by design, which would mean one DHCP server per subnet in a building with forty VLANs. The fix is a relay agent, usually the router itself. It listens on port 67 on the client-facing interface, and when a DISCOVER arrives it does not forward it: a router may not forward a limited broadcast. It builds a new unicast packet of its own, copies the DHCP payload in, and writes its own interface address into the giaddr field, the gateway address. That single field does two jobs. It tells the server which subnet the client is on, so the server knows which pool to draw from, since by the time the packet arrives the source address is the relay's rather than the client's. And it is where the server sends the reply, which the relay then puts onto the client's segment. Watch the ports while that happens: relay to server and server back to relay both run 67 → 67, because a relay speaks to a server the way a server does, and only the last hop, from the relay down onto the client's segment, goes to port 68. On Cisco IOS the whole thing is one line on the VLAN interface, ip helper-address 10.99.0.5.
Reservations, and why they are not the same as a static address. Some devices have to be findable at a fixed address forever: a printer, a badge reader, a camera. There are two ways to arrange that and they are not equivalent. A reservation is configured on the DHCP server: bind this MAC address to this IP address, and hand out that address and nothing else whenever this MAC asks. The device is still a completely ordinary DHCP client and still does DORA, still renews, still gets its mask and gateway and DNS from the server, and if the gateway changes next year it picks the change up on its next renewal like everything else. A static address is typed into the device itself, which then never speaks DHCP at all, so the server has no idea the address is in use and will cheerfully offer it to somebody else unless you have also excluded it from the pool by hand. A device with a static address that still wants the other parameters can ask for them with a DHCPINFORM, which asks for options without asking for an address.
The two ways this goes wrong, and the messages that say so. If a client ARP-probes its new address and something answers, the address is already in use by a host the server does not know about. The client sends a DECLINE to tell the server that address is poisoned, the server marks it unusable, and the client starts again from DISCOVER. In the other direction, if a client asks for an address the server will not give it, typically after a laptop moves to a different subnet and tries an INIT-REBOOT with the address it remembers, the server answers with a NAK, and the client drops the address and returns to INIT. A NAK is a refusal, not an error: it is how a host that has been carried between buildings is told to stop assuming.
05 Cheat sheet
What gets asked about DORA, and what gets answered wrong
Every row is something you can be asked to state in under ten seconds. The right-hand column is the specific wrong answer that gets written down, not a general caution.
| What they ask | The answer | The trap |
|---|---|---|
| The four messages, in order | DISCOVER, OFFER, REQUEST, ACK | Saying "DORA" and then not being able to expand it, or swapping OFFER and REQUEST. |
| Transport and ports | UDP · server 67, client 68 | TCP — a handshake needs an address the client does not have |
| Addressing on the DISCOVER | 0.0.0.0 → 255.255.255.255 | putting the server’s address in it — the client does not know it exists |
| What the client actually receives | address, mask, gateway, DNS, lease | Naming only the address. It is four settings plus the lease, not one. |
| Why the REQUEST is broadcast | so the servers whose offers lost can free them | Saying "because the client still has no address". True, but it is only half the answer. |
| When may the address be used | after the ACK, never after the OFFER | after the OFFER — an offer is a proposal, the binding is written on the ACK |
| T1 and T2 | T1 = lease / 2 · T2 = 7/8 of the lease | T2 = 3/4 — it is seven eighths, and the two crowd together on purpose |
| How a renewal is addressed | unicast to the leasing server, ciaddr filled, no option 50 or 54 | Broadcasting it, or repeating the whole DORA. A renewal is two messages. |
| What happens at T2 | the same REQUEST, but broadcast to any server | Thinking the client has lost the address at T2. It keeps it until the lease actually expires. |
| Server on another subnet | a relay agent · giaddr · ip helper-address | a router forwards the broadcast — it never does; the relay originates a new unicast |
| Same address for a printer, every time | a reservation on the server, keyed on the MAC | Typing a static address into the printer. The server then does not know the address is taken. |
| Nothing answers | 169.254.0.0/16, mask 255.255.0.0, link-local only | expecting internet access — there is no gateway and no DNS on a link-local address |
| DHCP for IPv6 | ports 546 client and 547 server · Solicit, Advertise, Request, Reply | 67 and 68 — DHCPv6 is a different protocol with different ports |
06 Where & why
Where the lease shows up on a machine you can log into
None of this is a teaching abstraction. Every value in section 02 is printed by a command you can run today, and two of the four systems below are where the security note at the end of section 03 actually gets fixed.
ip helper-address 10.99.0.5 on a VLAN interface makes the router a relay agent: it turns each client broadcast into a unicast to that server and writes its own interface address into giaddr. Worth knowing that the command forwards eight UDP services by default and not only DHCP, including TFTP 69, DNS 53, Time 37, TACACS 49 and the two NetBIOS ports 137 and 138. The other half is ip dhcp snooping: every access port starts untrusted, only the uplink towards the real server is marked ip dhcp snooping trust, and the switch drops any message that only a server is entitled to send when it arrives anywhere else. It also builds a table of MAC to IP to port, which Dynamic ARP Inspection and IP Source Guard then read.
A subnet4 entry declares the range the server hands out and the options that ride with it; a reservation binds one hw-address to one address, so a printer keeps the same address forever without anything being typed into the printer. valid-lifetime is option 51, and renew-timer and rebind-timer are options 58 and 59 for when you want to override the one half and seven eighths defaults. The lease database is the authority on who holds what: an entry that no host is actually using is exactly what an expiry exists to clear. Kea is the supported successor to ISC dhcpd, which reached end of life in 2022, though it is dhcpd.conf syntax that most exam questions still show.
ip -4 addr show prints a DHCP-assigned address with the word dynamic on it and a valid_lft in seconds that is smaller every time you run the command. That number is option 51 as the kernel sees it, and watching it jump back up to the full lease is watching the renewal at T1 succeed on a real machine. ip route then shows the default route that came from option 3, and resolvectl status shows the resolvers that came from option 6. Three commands, three of the four things the ACK handed over, and the fourth is the mask sitting next to the address as a prefix length.
ipconfig /all prints DHCP Enabled, DHCP Server, Lease Obtained and Lease Expires, so the entire lease including the identity of the server that issued it is on one screen. ipconfig /release sends a RELEASE and hands the address back; ipconfig /renew restarts the exchange. This is also where most people first meet a link-local address without knowing what it is, because when nothing answers, the line reads Autoconfiguration IPv4 Address and the value starts 169.254.
07 Interview questions
The questions, and the follow up that catches people
DORA is easy to memorise and that is exactly the problem: almost everybody can list four words, so the marks are in the second question. Expect to be asked what address is written on a message, or why one of them is broadcast, or what is different about a renewal. Say the addresses out loud while you draw the exchange; a description with no 0.0.0.0 in it reads as recited.
What does DHCP do, and what exactly does it hand a client?
Walk me through DORA, and tell me what addresses are on each message.
The client has no IP address. So how does the DISCOVER get anywhere, and how does the reply get back?
Why does DHCP run over UDP rather than TCP, and why are the ports fixed at 67 and 68?
Why is the REQUEST broadcast when the client already knows which server it wants?
At what point may the client start using the address?
Explain the lease, and what happens at T1 and T2.
The DHCP server is on a different subnet from the clients. How does that work at all?
A laptop shows 169.254.23.87. What happened, and what will still work?
Is DHCP authenticated? What can somebody on the same LAN do with it?
08 Practice problems
Six to work on paper
Draw the segment before you answer any of these: the client, the servers, the router, and an arrow for every message with its source and destination written on it. Four of the six turn on the difference between a client that owns an address and one that does not, and one of them is decided entirely by arithmetic you can do in your head.