Basic DHCP concepts
by Bill Wear on 17 June 2021
Let’s step back and take a very basic look at DHCP. In fact, let’s look at the analogy of assigning a street address to your house. Usually, this is done by the local 911 dispatch office, or some other central authority. They typically use either a survey map or a latitude, longitude pair to locate you, before they assign your house numbers from a pool of available addresses, compatible with other addresses in the area.
Let’s assume that you’re not sure who to call, so you just broadcast a message to everyone in range — your neighbors, the local authorities, etc. You explain that you’re at a given latitude and longitude, and that you need an address. You might grab a megaphone and shout into it.
“Hello. My LatLong is 80.0, 35.7. I need a street address! Can someone out there help me?”
It’s a long shot, you know, but it’s the only thing you can think of at the moment. And — surprise — someone authoritative answers you with an OFFER.
“Hello, LatLong 80.0, 35.7! I have a unique address of 62 Wimberly Place, here are the details. By the way, I am at 46 Reardon Lane if you need to reach me.”
You’re not going to miss this chance, so you let the authority know that, yes, you do want that address, just as they gave it to you. In fact, just to make sure, you formally REQUEST the address.
Hello? 46 Reardon Lane? I’d like to formally request that “62” address. Is it still available?
Happily, the authority ACKNOWLEDGES that the address is yours, or at least, for a while, anyway.
LatLong 80.0, 35.7, that address is still available. I’m marking it down to you! Enjoy!
We used “LatLong 80.0, 35.7” because this particular negotiation is basically carried out by shouting across the fences. Even so, the two participants have to know for sure they’re talking to the right party, so identifiers have to be used that are guaranteed to be unique. 62 Reardon Lane has their address, so they’re already unique. 80.0, 35.7 has no address, so they have to use something else that uniquely identifies them.
The network version of DORA
The DHCP negotiation process is known as DORA: Discover, Offer, Request, Acknowledge. Just like the exchange above, it’s carried out by the network equivalent of shouting, that is, broadcast exchanges. While the payloads for the messages carry unique addressing information (after the first DISCOVER message), the Destination IP (DIP) is always 255.255.255.255 — broadcast mode. Every machine on the network will see the packet, but they will ignore it when they look at the payload.
By the way, there are several other possible responses at various points in the exchange, such as NACK (from the DHCP server, when the client has waited too long to make the request) and DECLINE (e.g., when the IP address configuration offered isn’t usable by the client). We’ll cover those in another blog.
The network version of the shouting match above looks something like this:
You can read through the steps above: they’re basically self-explanatory. What isn’t always obvious is that the entire exchange takes place in broadcasts, rather than addressed packets. Said differently, the DIP (Destination IP address) is always 255.255.255.255, the broadcast address. The exchange becomes semi-private with the first OFFER, via the use of message payloads.
DORA in packets
In fact, it’s worthwhile to (very briefly) consider a DHCP packet exchange. Typically, it looks something like this:
DHCP Discover Ehternet Header: DA=FF-FF-FF-FF-FF-FF, SA=<client MAC> IP Header: SIP=0.0.0.0, DIP=255.255.255.255 DHCP Payload: Client MAC=<client MAC> DHCP Offer Ethernet Header: DA=FF-FF-FF-FF-FF-FF, SA=<DHCP server MAC> IP Header: SIP=<DHCP server IP address>, DIP=255.255.255.255 DHCP Payload: Offered IP=<offered IP>, Client MAC=<client MAC>, Subnet Mask=<Subnet mask>, Router IP=<router IP>, DNS=<DNS server1 IP, DNS server2 IP>, IP Lease Time=<time>s, DHCP Server Identifier=<DHCP server IP address> DHCP Request Ethernet Header: DA=FF-FF-FF-FF-FF-FF, SA=<client MAC> IP Header: SIP=0.0.0.0, DIP=255.255.255.255 DHCP Payload: Client MAC=<client MAC>, Requested IP Address=<offered IP>, DHCP Server Identifier=<DHCP server IP address> DHCP Ack Ethernet Header: DA=FF-FF-FF-FF-FF-FF, SA=<DHCP server MAC> IP Header: SIP=<DHCP server IP address>, DIP=255.255.255.255 DHCP Payload: Offered IP=<offered IP>, Client MAC=<client MAC>, Subnet Mask=<Subnet mask>, Router IP=<router IP>, DNS=<DNS server1 IP, DNS server2 IP>, IP Lease Time=<time>s, DHCP Server Identifier=<DHCP server IP address>
We could certainly spend quite a long time decoding these packets, and explaining — in detail — each of the parameters. For this article, though, let’s just focus on a couple of things:
- The DHCP server provides all the needed configuration parameters in both the OFFER and the ACK messages. Nothing is left out: the client receives an IP address, a subnet mask, a router location, the IPs of both DNS servers, the lease time limit, and the identity of the DHCP server. Nothing else is necessary for the requesting client to begin operating independently on the network.
- The requesting client does not start using the offered IP address until it has received the ACK message. Note that in the DHCP Request, above, the SIP (Source IP) is still 0.0.0.0, even though the client knows the offered IP (it sends it back in the request to confirm).
There you have it, a very basic view of DHCP. Next blog, we’ll talk at length about how multiple DHCP servers and multiple requesting clients can keep things straight.
Back a few months ago, we did a feature poll on our MAAS forum, and the most-requested new feature turned out to be “Recommission/rescan a machine after it has been deployed“. With the release of MAAS 3.1, we’ve added that feature, making MAAS an even better choice for linux deployment tools. Here’s a sample of […]
We are happy to announce that MAAS 3.1 has been released. Bare metal provisioning just got even easier! MAAS 3.1 brings some of the most frequently-requested features into the product. A lot of this is serendipity — or maybe you could say that it’s about like minds tracking the same problem. Either way, we’re doing […]
We want to make it possible to deploy MAAS in an existing datacenter, and have it keep track of machines that already have a deployed workload — without disturbing machine or workload. Currently, in order to get a machine into MAAS, with correct hardware information, you have to network boot the machine and let MAAS […]