In the early days of TCP/IP, everything
dealing with the configuration of an IP
address, a subnet mask, a default
gateway, or any other IP parameters,
was all a manual process.
You had to visit every single workstation,
or every single device on the network,
and you had to manually configure
all of these settings.
This wasn't bad when you had a handful of devices,
but when you have hundreds, or even
thousands of devices that have to be configured,
visiting every single device is not a very practical way
to provide this configuration.
So in October of 1993, we came up
with an automated process for assigning these IP addresses,
and we call this the Bootstrap Protocol, or BOOTP.
Unfortunately, BOOTP didn't configure everything
that we needed in the IP configuration.
There were still a number of parameters
that had to be configured manually,
but BOOTP didn't know when someone left the network,
or when an IP address might have been made available again.
So we updated BOOTP with a new protocol,
called the Dynamic Host Configuration Protocol,
or DHCP.
We created DHCP in 1997, and we've
made updates to the protocol throughout the years.
Not only can DHCP provide these automated configurations
that we need, but it can recognize when IP address
leases may be over, and assign those IP
addresses to other devices on the network.
Let's go through the process that DHCP
uses when someone connects to the network
and needs an IP address configuration.
In this network, we have Sam on one side, Jack is on the other.
Sam is connected to a switch, and on that local network
with the switch is a DHCP server.
There's also a router connecting sites together,
and Jack is at this other site, connected
to that router with a switch.
Let's take the configuration of Sam connecting to the network,
and needing an IP address.
This starts with Sam sending a DHCP Discover
message from 0.0.0.0--
because Sam does not have an IP address--
and this is sent using UDP port 68 to 255.255.255.255.
And if you recall, that is the broadcast address
for a network.
So every device that is on this local network
will see this message that Sam is sending, including the DHCP
server, and Sam is sending that broadcast to UDP port 67.
So Sam sends that message.
Because it is a broadcast, that broadcast
is sent to all devices on the network.
A DHCP Discover message sent to a router that
doesn't have any DHCP services running
would simply ignore that broadcast,
but the broadcast does make it to the DHCP server that
is on that local network.
Now that the DHCP server has seen the Discover message
from Sam, it wants to send a message back
to Sam with some potential IP addresses that Sam can use.
So the DHCP server sends a DHCP Offer message from its local IP
address, which is 10.10.10.99, using UDP port 67,
and it sends this to a destination address
of 255.255.255.255.
The reason the DHCP server is sending this message out
as a broadcast is because Sam doesn't have an IP address yet,
so there's no way to unicast that particular message
to Sam's workstation.
That all 1s broadcast is sent to UDP
ports 68, and Sam is listening in
to see if any of these broadcast messages are received,
and that offer message is received by Sam's device,
because it was sent to all devices on the local network.
Sam is now received this offer a message from the DHCP server,
and that offer message does have an IP address configuration
that Sam can use.
But before Sam can use that IP configuration,
a DHCP Request message is sent from Sam's workstation, which
is 0.0.0.0, port 68 over UDP, to an all 1s broadcast of UDP port
67.
And that message is sent to the server,
saying that the IP address that we have received looks good,
and we would like to use that IP address.
This final step is the DHCP server
acknowledging that IP address is one that can be used,
and can be configured on that local device.
The DHCP server will send a DHCP Acknowledgment message
from the DHCP server to an all 1s broadcast, over port UDP 68.
At this point Sam's workstation configures itself
with the IP address that was originally sent in the Offer,
and ultimately acknowledged in step four.
As we were going through that four-step process,
you may have noticed that everything was
being sent through broadcasts.
And of course, broadcasts have no way to traverse routers.
In a large enterprise environment,
this becomes difficult to manage,
because you don't want to have to put individual DHCP
servers on every local subnet.
Instead, what we want to do is provide some way
to have redundancy, so there are multiple DHCP servers
to choose from, and we might also
want to have multiple servers to handle the load of all
of these devices wanting to configure themselves with IP
addresses when they start up.
So we might want to put DHCP servers in key, critical places
around the network, but still provide
a way for all of the devices to access those servers,
even though they're still using broadcasts.
To be able to do this, we use what's
called a DHCP Relay, or IP helper function,
to be able to relay the message from the broadcast
directly to a local DHCP server.
Let's look at the same network configuration,
but in this case, let's look at Jack's workstation.
When Jack turns on his computer, he
needs to have an IP address configured.
But you'll notice there are no local DHCP
servers on Jack's subnet, so simply sending broadcast
to that subnet will not have any response,
because those messages will never
make it to the DHCP server that's
on a different IP subnet.
Instead, we're going to configure this router
with a special configuration setting called a DHCP Relay.
You may also see this referred to as an IP Helper.
We're going to tell this router that if it ever receives
a message for DHCP, to please transfer that message
to the DHCP server that's currently located
at 10.10.10.99.
And as you'll notice, that is the IP address
of the DHCP server that's on the other broadcast domain.
From Jack's perspective, the process
is exactly the same as the one that Sam went through.
Jack has no idea that there's a relay in place.
Jack is simply going to send the Discover message to an all
1s broadcast at UDP port 67.
When that Discover message is received by the local router,
the router recognizes that there is a DHCP Relay configured,
and it changes the source address of the request
to 10.10.30.1, which is the router,
and the destination address to 10.10.10.99,
which is the DHCP server.
This means the router can send a direct message to the DHCP
server without any worries of broadcast domains.
The DHCP server is then going to send a DHCP offer request,
just as it did when it sent an offer to Sam, but in this case,
the DHCP server is going to send the message to 10.10.30.1,
because that's the IP address that was received
by the original Discover address.
That message is then going to be sent back
to the router, who of course recognizes the DHCP Relay
configuration, and changes the IP address to be
a broadcast for the local network,
effectively making it exactly the same process
that Sam went through, except now there's
a router in the middle that provides this additional relay
function.
The rest of the process continues exactly the same way
it did for Sam, except now we have a relay in the middle
to handle the request and the acknowledgment,
so that Jack can then have his IP address configured by a DHCP
server that sits on a different broadcast domain.