Most of us receive an IP address automatically when we start our computer. In this video, you’ll learn about automatic IP address assignments and what happens when a DHCP server isn’t available.
In a previous video, we talked about a manual configuration of an IP address that includes an IP address, a subnet mask, a default gateway, and a DNS setting. And of course, there are other IP configuration settings as well. You can imagine on an enterprise network, where you have hundreds or even thousands of devices, manually configuring IP addresses is not going to scale very well. And that’s why in October of 1993, we created a protocol that can automatically assign IP addresses to devices. We refer to this as the bootstrap protocol or BOOTP.
BOOTP was a good start, but it didn’t assign all of the different configuration settings that we needed. There were still some manual configurations that you had to do yourself. And BOOTP had no idea when a device would leave the network, so that it could use that IP address for another device later on. To correct some of these shortcomings, we created a new version of BOOTP. And we gave it a new name, the Dynamic Host Configuration Protocol or DHCP.
DHCP has been around for quite some time since 1997. And it provides an automatic configuration of IP addresses, subnet masks, default gateways, and many more settings as well. We often don’t even think about the process that DHCP goes through to assign these values to your computer. We simply turn on our system, and it magically has an IP address once it boots up. But behind the scenes there are a series of steps that take place to provide that IP configuration to your device.
We refer to these four steps as D-O-R-A or Dora. The first of these is the D step or discover, where our devices will try to locate a DHCP server that’s on our local network. The next step of O is to offer where a DHCP server will offer an IP address to our device. Our device will then look at the one or many offers that we receive, pick one of those offers, and then request that IP address from the offering DHCP server. And finally, the DHCP server will acknowledge that offer and provide your system with all of the IP configuration settings that it needs.
Let’s look at each of these steps to see exactly how this process occurs on our network. Here’s a simple network diagram that includes my client workstation, which is connected to a switch. And that switch I also have connected a local DHCP server on my local subnet. And I have a router that’s on my network as well. On the other side of that router, on a separate IP subnet, is another DHCP server so that we can have some type of redundancy if either one of those was to fail.
The step one of the DHCP process or the discover part of the process has my client workstation sending a broadcast out to the network to UDP port 67. This broadcast will be sent to all devices on my local network. And that broadcast is going to be sent both to the router that’s on my network and the DHCP server that’s on my network. One of the things that you probably remember from looking at broadcast multicast and unicast is that routers will not allow broadcast to pass.
But you’ll notice in our example, the broadcast did pass through this router and was directed to a DHCP server. That’s because we’ve effectively configured this router as a DHCP proxy. You’ll sometimes see this referenced as a DHCP relay, and some manufacturers call it an IP helper. This obviously requires that you pre-configure this router so that any broadcasts associated with DHCP are automatically forwarded to a DHCP server elsewhere on the network.
Now that these two DHCP servers have received our request, we can move to step two or the offer phase. These two devices will send their offers back to the original client workstation. This is often sent to a broadcast address over UDP 68. The reason we’re using so many broadcasts is because, remember, our client workstation does not yet have an IP address. Now that this message is sent to the client workstation, it can examine both of those offers and make a decision on which offer it should take for the IP address assignment.
The client workstation will send another broadcast over UDP port 67 on step three or the request phase. This broadcast contains a formal request to take the offer that was originally sent. And in this particular example, I’m only showing the communication that’s occurring between the client workstation and the DHCP server that made the original offer. But of course, since this is a broadcast, it would be sent to all other devices on this local subnet. And now that the DHCP server has received this formal request, it can begin step four or the acknowledgment phase where it sends a message back to the client workstation by default over UDP port 68 confirming that the request from the previous phase has been acknowledged, and this device can assign itself with the configuration settings included in the offer.
This four step DORA process happens every time a device connects to the network and needs to obtain an IP address from a DHCP server. When these DHCP servers were first configured, a range of IP addresses was configured inside of that server to hand out to the different clients. We refer to this as a pool of IP addresses. And the IP address that you may pull one day from this pool may be different than when you might use on a different day. But there might be some devices on your network that you would prefer always receive exactly the same IP address every single time it starts up.
There might be a printer, a server, or some type of infrastructure device that you would prefer to always have the same IP. One of the ways you could do this is to simply disable DHCP on all of these devices and manually configure the IP addresses yourself. This obviously requires that you administratively make this change. And if you make any changes to the IP address settings on your network, then you’ll manually need to revisit these devices to change all of your previous configurations. In a very large environment this may not be very practical. And it certainly requires additional administration.
So instead of manually setting an IP address, we can configure a reservation on the DHCP server. This means we’ll configure a specific MAC address of a printer, a server, or another device on the network, and tell our DHCP server every time you see this MAC address, always provide it with this reserved IP address. This way every time we start up the printer or the server, it will always have exactly the same IP address. This is the best practice for IP address configurations because we know it’s so easy to set a manual address. The problem is that when there are changes to the network, you’ll have to go back to every single one of those devices. So having a reservation already in the DHCP server can make this process so much easier than revisiting all of these different devices on your network.
There may be times when your device is configured to obtain a DHCP address, but on your local network there’s no longer a DHCP server. In those situations your device will be assigned an APIPA address. That stands for an Automatic Private IP Addressing Address. This is sometimes referred to as a link-local address, because any device that’s configured with an APIPA address range can only communicate to other devices on the local network. If your device is assigned an APIPA address, it can’t communicate outside of your local network.
Like most things, there is a standard for the automatic private IP addressing. The entire range is 169.254.0.0 through 169.254.255.255. This particular standard reserves the first and last 256 addresses. So if you are assigned an APIPA address, it will be a random assignment between 169.254.1. 0 through 169.254.254.255. If you see any of those IP addresses on a system, then you can automatically assume that a DHCP server was not available when the system started up. And you will only be able to communicate with other devices on your local network.
Like DHCP, APIPA addresses are also assigned to automatically. But the only device determining what IP address you receive is your local device itself. Your local device will pick a random IP address that’s in this APIPA address range. It will perform an address resolution protocol or ARP request to see if anybody else on the local network is currently using that IP address. And if it doesn’t receive a response, it assigns signs that APIPA address to your local device.
Here’s what you would see if you ran an ipconfig/all on a Windows device that has an APIPA address assigned. You can see that the IPv4 address configuration even states that it is an autoconfiguration address. And it is assigned 169.254.228.109 with the default subnet mask for APIPA of 255.255.0.0. And because you can’t communicate outside of this local network, you can see that the default gateway option has been left blank.