What is DHCP and how does it work?
Like many things in the world of electronics and computers, it would take many posts to cover every aspect of what DHCP is in its entirety.
Because of this, I’m going to make a few assumptions about you, the reader.
First, I assume that you have a few computers/devices at home on a small network with a router as the default gateway and have some interest in how all things electronic (including computers) work.
Secondly, I assume that you’re an electronics enthusiast and may wish to build a project that can connect to a network using DHCP.
Third, you’re not a network administrator of a large corporation or university. Because of this, we’ll cover the basics of DHCP and how it works, but won’t be covering more advanced features of DHCP in detail. Nor will we discuss installing and/or configuring DHCP on a server running a network operating system (NOS) like Windows Server 20xx.
Now let’s answer the question: what is DHCP?
What is DHCP?: The Macro Level
DHCP stand for dynamic host control protocol.
Every host or device on a TCP/IP network needs to have a unique IP address.
Back in the day, administrators of TCP/IP networks would manually assign nodes (computers and printers on the network) IP addresses.
Sometimes, administrators would accidentally assign the same IP address to two different nodes.
Doing so would cause all sorts of network pandemonium.
To prevent this, DHCP was invented.
DHCP services run on a DHCP server, where they control a range of IP addresses known as a scope.
A DHCP server is simply a device on the network that keeps track of what IP addresses are available and then parcels them out to nodes that request an IP address from the server.
This could be something as simple as the wireless router in your home or a whole server computer dedicated to just DHCP for very large networks. A DHCP server can also be software or part of the OS that runs on a file server. In this case, the file server would share its resources with other programs and tasks besides just DHCP.
When a DHCP server assigns an IP address to a client computer (or node) the address is said to be leased. Leases usually last for a finite amount of time and expire. Once they expire, the client can send a request to renew lease.
DHCP provides more information than just the IP address to the client computers (more on this a bit later).
What is DHCP & How Does It Work? (Still Marco Level)
This basic overview of how DHCP works can be helpful when working with computers or writing code for microcontrollers which will find their home in whatever widget you’re working on.
It may also help you troubleshoot networking issues.
What follows below happens every time a node boots up or connects to a network. It also happens when an IP address is released from a node or a fresh lease is requested by the node.
When your computer or microcontroller-powered device turns on, the DHCP client software sends a special broadcast packet known as a DHCP discover message. This is same as your device shouting “Hey, I need an IP address. Any DHCP servers out there?”
When the DHCP server receives the discover message, it will send a DHCP offer message, which includes an IP the client can use. If the client never gets the offer message it will wait a few seconds and try again four times. If it still doesn’t get the offer it will try again in five minutes.
Once the client gets the message, it sends a DHCP request message. This sounds redundant, but at this time the client doesn’t own the IP, it’s simply saying “Yes, I’ll take that IP address. Can I have it now?”
When the DHCP server receives the DHCP request message it will mark the IP as assigned to whatever client has it and then send an DHCP ack (acknowledge) message.
The server then sends the rest of the information the client needs to use it.
Earlier, I said that DHCP does more than just provide IP addresses. Let’s delve into this a bit.
What is DHCP & How Does It Work?: The Micro Level
If you ask the average electronics or computer enthusiast “what is DHCP?”, they’ll probably reply with something like “that’s how my computer (or widget) gets its IP address.”
This is true, but there is a lot more to DHCP than meets the eye.
First, DHCP is an extension of an older protocol – the bootstrap protocol (BootP).
BootP was used for diskless workstations at one time but has since joined the dinosaurs so it’s not something you’re likely to run into. People did not love diskless workstations. Basically, the protocol sends a boot image file over the network to a given diskless workstation so it can boot. It also gave the workstation an IP address like DHCP.
DHCP information passes from server to client in form of messages like the one from figure 1.
Figure 1: a DHCP message.
Let’s go through each of these fields and explain them a bit more.
The op field consists of an octet (same thing as a byte) that houses the DHCP message’s op code or message type. For example, a BOOTREQUEST would place a 1 in the field and a BOOTREPLY places a 2 in the field.
When a client sends a discovery message the op field has a 1 in it.
The next field to the right is the hardware address type (htype). A 1 in this field means the htype is Ethernet. Other values (2-35) exist and denote other things such as Token Ring, ARPSec and more.
Not surprisingly, the hardware address length (hlen) field gives the length of the hardware MAC address. For Ethernet or other networks using IEEE 802 MAC addresses, the value is 6.
MAC stands for media access control and is an address which the manufacturer programs into the hardware. Note that no two devices made anytime, anywhere should have the same MAC address.
The hops field is used by relay agents to control the forwarding of BOOTP and/or DHCP messages. Relay agents are mostly associated with the BootP protocol, so it’s not something you’re likely to need to worry about.
The xid field contains a random number chosen by the client that it uses to associate a DHCP message with a DHCP server. This comes in handy if there are multiple DHCP servers on the network. It is four octets long.
Next, we have the secs field. This one is also controlled by the client and contains the number of seconds that have passed since the client sent a boot request. A busy DHCP server may use this to prioritize replies when multiple client requests are outstanding.
The flags field comes next. The first bit of the first octet of this field is a 1 when a broadcast message initiates. A client that doesn’t know its own IP address at the time it sends its request would set it to 1. The other 15 bits are unused and reserved for future use. These need to be 0.
The ciaddr field is the client IP address field. The client populates it with its IP address, but only during a renew, bound, or rebinding operation. The client can only use this field when its address is valid and usable, not during the process of acquiring an address.
A DHCP lease will eventually expire. When this happens, a renew operation takes place which gives the client another (likely the same as before) IP address.
Being bound is being in the state of acceptance of the network parameters (including an IP) from a DHCP server. Rebinding is the process of gathering binding information to see if the client will choose to be bound to a particular DHCP server.
Using the ciaddr field also requires the device (or client) to understand ARP, another protocol which will probably show up in a future post.
In the yiaddr field, the DHCP server puts the IP it is offering to the client. An easy way to remember what this field does is to think of the y as “yours” as in “your IP address.”
Another field that you’re unlikely to use is the siaddr or server address field. It is the address of the server that the client should use for the next step in the bootstrap process, which may or may not be the server sending this reply. The sending server always includes its own IP address.
The giaddr field is the gateway IP address field and contains the relay agent’s IP address that the client is booting from. As with the previous case, the average person probably won’t need to worry about this field.
Inside the hlen field, the number of octets or bits the hardware address contains is designated.
Although the chaddr (client hardware address) field is 16 octets, we only need to fill in the as many octets as the MAC address uses.
The longest fields are the sname (server host name) and file fields which contain 64 octets and 128 octets, respectively.
The server sending a DHCP offer or DHCP ack message may optionally put its name in sname field. This can be a simple text “nickname” or a fully-qualified DNS domain name (like computers.circuitcrush.com).
The file field can be optionally used by a client to request a particular type of boot file in a DHCP discover message. It can be used by a server in a DHCP offer to fully specify a boot file directory path and filename.
Both fields are primarily for network boot situations, so you likely won’t have to worry about them.
Finally, the options field varies in length and holds DHCP options, including several parameters required for basic DHCP operation. Some of these include the end option, which is 255 or 0xFF in hexadecimal, the subnet mask option, router option, and more.
When a client is in request mode, it includes the option variables in this field. The DHCP message returned to the client has the operation parameters plus the info associated with the requested option embedded within the option field.
I don’t blame you, but all the information I could muster up on this field was confusing and poorly explained.
The picture below should help clear things up, however.
Figure 2: A packet sniffer decode of a DHCP discover message.
Figure 2 shows a packet sniffer decode of a DHCP discover message and should shed some light on how DHCP works and what all the fields are for.
You may recognize some of the fields above the black rectangle from previous discussion.
Within the black rectangle are the options we’re talking about.
Interestingly, the vendor information tag is also called the magic cookie. There are a few other options in between that and the end of options = 255 line, which is self-explanatory.
This options field may contain different options depending on the message type and the sender (client or server).
Now We Know What DHCP Is & How It Works
Or at least some basics on how DHCP works. As always, there is a lot more to say about DHCP but this short tutorial should give you some understanding of what DHCP is and how it works in case you need to write some code for it.
Sure, your Arduino, PICs, and other platforms and microcontrollers may have libraries you can just pop into your code to handle this, but real nerds want to know how things work 😉
Have you used DHCP in any of your projects? Comment and tell us about your experience and best tips!
- Lowe, Doug. Networking All-In-One Desk Reference for Dummies, 3rd Ed. Wiley Publishing, Inc., 2008. Print.
- Best, Peter. “The Dish on DHCP.” Nuts & Volts October 2006: 87-92. Print.