Search code examples
networkingdhcp

Why request dhcp packet is neccessary?

In DHCP protocol we have 4 packets named DORA.

first of all client send a broadcast Discovery packet for detecting DHCP server.

Then server send a Offer packet contain ip, subnet and many options and waiting for client.

If client find Offer packet suitable, send a broadcast Request and get ACK or NAK.

But why ?

Why we can't ignore Request packet and replace this way to sending 3 packets.

Discovery, Offer and ACK.

client -> Discovery
server -> Offer
client -> ACK

Why this way is not secure or suitable ?

Solution

  • When the client broadcasts the Discover packet, it may get Offer packets from multiple DHCP servers. The purpose of the Request packet is to say to one of the servers, "I want to use the IP address that you offered to me". If that wasn't sent:

    • the server whose offered IP the client is going to use wouldn't know not to offer that IP to a different client, and

    • the other servers wouldn't know that they can offer their IPs to other clients.

    Then the final Acknowledge packet tells the client that the server has gotten the Request, and that the client now has the "lease" on the IP address.

    This is intended to ensure that:

    • IP addresses are not wasted because a server thinks the client is using the Offered IP, when the client is actually using a different server's Offered IP.

    • The same IP is not accidentally leased to two clients at the same ... which causes chaos.

    In the variation that you proposed, suppose that the ACK packet from the client to the server is lost. Now the server won't realize that the client is going to use the Offered IP address. A few minutes later, it could then Offer the same IP address to a different client and ... chaos ensues.

    Please don't imagine that the people who design internet protocols are dullards. They have thought these things through carefully before they write the RFCs. And many other (equally smart) people have gone over the pre-approved RFCs carefully looking for problems. So, if there is something about a standard protocol that you think is wrong, it is likely to be >>you<<, and not the protocol designer who is mistaken. Or, at least, the original "mistake" is understandable in the historic context.