RSS
Twitter
Facebook
Dynamic Host
Configuration Protocol (DHCP) is a network protocol that enables a server to
automatically assign an IP address to a computer from a defined range of
numbers (i.e., a scope) configured for a given network.
DHCP assigns an
IP address when a system is started, for example:
1. A user turns
on a computer with a DHCP client.
2. The client
computer sends a broadcast request (called a DISCOVER or DHCPDISCOVER), looking
for a DHCP server to answer.
3. The router
directs the DISCOVER packet to the correct DHCP server.
4. The server
receives the DISCOVER packet. Based on availability and usage policies set on
the server, the server determines an appropriate address (if any) to give to
the client. The server then temporarily reserves that address for the client
and sends back to the client an OFFER (or DHCPOFFER) packet, with that address
information. The server also configures the client's DNS servers, WINS servers,
NTP servers, and sometimes other services as well.
5. The client
sends a REQUEST (or DHCPREQUEST) packet, letting the server know that it
intends to use the address.
6. The server
sends an ACK (or DHCPACK) packet, confirming that the client has a been given a
lease on the address for a server-specified period of time.
When a computer
uses a static IP address, it means that the computer is manually configured to
use a specific IP address. One problem with static assignment, which can result
from user error or inattention to detail, occurs when two computers are
configured with the same IP address. This creates a conflict that results in
loss of service. Using DHCP to dynamically assign IP addresses minimizes these
conflicts.
Figure 1
In figure 1, a
new client that just joined the network, needs an IP address. Since it does not
know the DHCP server's location, the client broadcasts (step 1) a DHCPDISCOVER message
on the local network. The message packet contains a hardware identifier
(usually the MAC address), the source port (68), the destination IP
(255.255.255.255), destination port (67), and a randomly generated transaction
id. Optionally the client can specify the IP address it wants and the lease
duration in the message. Once the DHCP relay receives the broadcasted message,
it fills in the "giaddr" field of the packet with the gateway IP
address of 10.1.2.9 . This piece of information is critical because the DHCP
Server needs it to determine which subnet the client is on and thus which IP
address to allocate to the client. Afterwards the DHCPDISCOVER message is
relayed to the DHCP Server via unicast (step 2). A unicast, instead of a
broadcast, is sufficient because the DHCP relay knows the exact location of the
DHCP server. For this same reason, the DHCP relay does not allow the other
network segment, 10.1.1.X, to receive the message.
Once the DHCP
server receives the DHCPDISCOVER request, it allocates an IP address, marks it
as taken, and then broadcasts a DHCPOFFER message back to the requesting
client. This message packet contains the DHCP server's IP address, the client's
hardware identifier, the same transaction id, and the IP address allocated for
the client. Optionally, the messagemay also contain the lease time, subnet
mask, default TTL, default router(s), and numerous other parameters.
Figure 2
Figure 3
If the client
included optional information in the initial DHCPDISCOVER message, it must include
that same information in the subsequent DHCPREQUEST message. In step 6 of figure
3, the new client confirms it wants the IP address 10.1.2.3 by broadcasting a DHCPREQUEST
to the DHCP server. Once the DHCP Server receives this message (with help again
from the DHCP Relay), it first ensures that it is the intended target - because
the client could be responding to another DHCP Server. If this DHCP server is
not the intended target, then it knows some other DHCP server is handling this
client. So this DHCP server
can discard any
previously allocated IP address for that client. If this DHCP Server is the intended
recipient, then it has to verify the optional parameters that it specified in
the previous DHCPOFFER message to this client, are still valid. Assuming everything
is fine up to this point, the DHCP Server sends a DHCPACK broadcast (step 8) to
tell the client that its new IP address can now officially be used. However, if
something is wrong, then a DHCPNACK is broadcasted instead. Either way, a
DHCPACK or DHCPNACK will be the final message sent by the DHCP server in the
dynamic IP address allocation sequence..
Assuming it
receives the DHCPACK relayed by the router (step 9), the client is encouraged to
verify no other hosts has the same IP address. This is usually accomplished
through a simple ARP probe. Any response to the probe means that another client
is already using the IP address. In such a situation, the client must send a
DHCPDECLINE message to the DHCP server. Afterwards the client will then need to
restart this whole process beginning with DHCPDISCOVER phase. In most cases,
there's no response to the client's ARP probe. This means the client can go
ahead and use the allocated IP address along with any other optional information
stored in the message packet.
If the client
got a DHCPNAK instead of DHCPACK, then it has no choice but to restart everything
from the very beginning i.e. the DHCPDISCOVER stage. Finally, if the client doesn't
receive any DHCPACK or DHCPNAK message after a certain period of time, then it rebroadcasts
the DHCPREQUEST message.
0 comments