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.