Now we're going to move on and discuss the DHCPv4
address assignment packet flow.
These are the four packets that move back and forth
between the client and the server.
We're going to take a few minutes and discuss what these four packets are and
essentially what they mean in plain English as it were.
The first coming from the client to the server is the DHCPDISCOVER packet.
Now the DHCPDISCOVER packet is a broadcast packet coming from the workstation,
and it's essentially looking for a DHCP server on
the subnet that it's connected to.
And again, if you don't have one on the local subnet,
you can use a relay agent to relay that information
back to a centralized server.
If the client had an IP address,
it can optionally ask for the same IP address that it had before.
It can say, hey I had 192.
168.
15.
5, is there an authoritative server out there that can lease this address to me?
The next packet in the flow is where the server
responds back with the DHCPOFFER packet.
Now the DHCPOFFER packet is essentially the server saying,
okay I can service your IP address request,
I'm going to reserve an address for you and I'm going to send an offer back
to you and it contains the IP address that I'm offering,
subnet mask, the lease duration,
and the IP address of the server that's actually making the DHCP offer.
This is also a broadcast packet because again,
the client doesn't actually have a unicast IP address yet,
but since it does have an IP stack it has to honor,
or process, all broadcast packets sent to it.
Once the client receives the DHCPOFFER packet,
the next packet is the DHCPREQUEST.
Now it might seem odd to you that the client has just
received a DHCP offer from a DHCP server,
why it would then send a request packet right back to the server and say,
yeah, I know you offered me this address,
I'd like to request this address from you.
And when I first started dealing with DHCP, I had the exact same question.
Well, you've just offered me an address, why do I need to request it?
And the answer is because you may have multiple offers from
multiple different DHCP servers to the client.
The client obviously will only accept one of the offers and
only send a request to a single DHCP server.
Now the DHCP request is a broadcast as well coming
from the client because again,
the client still does not actually have a valid unicast address,
and so all of the servers know which offer was accepted because
the client puts the server ID in the packet,
and again, you'll see this when we look at in Wireshark.
And so that's how the DHCP server knows,
hey he's accepting my offer and all of the other DHCP
servers withdraw their offer and return their IP address
to their usable IP address pool.
Finally, once the DHCP server receives the DHCP request,
it replies back with a DHCPACK, or DHCP acknowledgment.
And once again, just like all the other packets in this flow,
this is also a broadcast because until the client receives
the acknowledgement back that the DHCP server has actually
leased the address to the client,
it still doesn't actually have a valid IP address.
However,
once the acknowledgment comes back the DHCP client can then
perform further communications in the future with the DHCP
server using unicast addresses.
We'll talk about how that works here in just a moment when we talk about
the T1 and T2 rebinding times that happen with DHCP.
You'll also notice if you look at this packet flow that the discover,
offer, request, and acknowledgment spells DORA,
D-O-R-A,
and that's how some documentation actually refers to this
four-packet exchange as the DORA Exchange.
Not to be confused with the small, Hispanic girl from the kids television show,
and my kids used to watch that when they were little and sometimes I'll start
singing one of the songs from the show just to annoy them.
My oldest thinks it's kind of cute, my youngest thinks I'm being insulting,
but anyway, that's neither here nor there.
That's the full DHCP packet flow in a nutshell.
Now this assignment process can assign IP addresses
using three different methods.
The first is dynamic, and it's the most common.
The IP address is leased to the client for a specific period of time.
You set that as the DHCP lease time,
it's usually a few hours or a few days depending upon the application that
you're wanting to service on that particular subnet.
As the IP address is nearing its lease end,
the client will request that address be re-leased to it,
and under normal circumstances it will receive the same IP address.
Out of all of the DHCP implementations out there,
again, this is the most common.
This is the one you'll see in 90% of all of your networks.
You also have the option of what's called automatic DHCP assignment,
and essentially it uses the same DORA method to assign a
permanent IP address to the requesting workstation,
so the requesting workstation always gets the same IP address
based upon the configuration in the DHCP server.
And finally, you have manual, or static,
allocation, and that essentially disables any kind of dynamic allocation,
either actually dynamic or automatic allocation,
and makes you as the administrator go into the DHCP server and put
in the MAC address or other identifier and only those MAC
addresses will actually get IP addresses,
everything else will just be ignored.
I'll be honest, I've never actually set up a network like this,
although I can see where certain internet providers for
their cable modems or their DSL modems may want to set up
a manual or static allocation.
And again,
this goes back to the previous statement where you don't want
anyone just hooking any device up to your network,
whether or not they're a subscriber, and getting internet access.
Now I'll admit,
I've never actually worked for an internet provider of any notable size,
so I could be way off on this supposition,
but I can see where this about the only application for a manual or static DHCP server.