There are 4 steps in DHCP: Discover, Offer, Request and Acknowledge.
Why is the third step called "Request"? No one is requesting anything at this step, are they?
The client simply is saying that it will accept the IP given by the DHCP server.
Where is the "request" portion at this step?
Yes, something is being requested.
You can read the conversation like this:
Computer: "I need an IP address!" <-- This is the discover
Server: "I have 10.11.12.13 available." <-- This is the offer
Computer: "May I have have 10.11.12.13?" <-- This is the request
Server: "Yes, you may." <-- This is the ack
There's a lot more to it than this, but essentially this is the process. It makes sense when you consider the coversation could go like this:
Computer: "I need an IP address!"
Server1: "I have 10.11.12.13 available."
Server2: "I have 10.11.12.19 available."
Server3: "I have 10.12.1.2 available."
Computer: "May I have 10.11.12.13?"
Server1: "Yes, you may."
In this case, there are three DHCP servers that all heard the discovery packet, and all three responded with an offer. The client "selected" the first offer it got and replied with a request to Server1, which it granted because the address was within its scope and was available.
Server2 and Server3 never got a request, so they do not allocate the IPs they offered, making them still available. If you did not have the extra request step, one client would've depleted 3 IP addresses instead of just one.
The client does not have a lease yet and is requesting one, so it's called a "Request". It requests that a lease be issued, verified, or extended.
The third step is "I (client) would like to use that ip from you (server)". As the next step is the server ACKnowledges or NotAcKnowleges it, it would sound silly that the server has to acknowlege an accept.
I really like Wes Sayeed's answer. Multiple DHCP servers could be one reason why the request is useful.
Here's another reason: trying to re-use the same address as before.
The request is a request for permission to use the address. The Discover, Offer, Request, Acknowledgement is sometimes called DORA.
#1: DISCOVER : Client asks the network (via broadcast message) for a DHCP server
#2: OFFER : DHCP server responds, and provides a potential address
#3: REQUEST: The end user machine/device sends a request to the server, requesting that the DHCP server allocates/reserves/uses up the requested address for that device
#4: ACKnowledge : If the response is an ACKnowledge, not a NACK (negative acknowledgement), then the request is considered to be granted.
Here's the tricky part: The request doesn't need to match the offer.
For example: If a laptop went off-network for a while, and then tries to connect (to the same network or a different one), the laptop might want to use the same address if possible. Here is a sample made-up conversation:
#1: DISCOVER: 0.0.0.0 asks 255.255.255.255 : "Can I have an address offered and know who you are?" The Layer 2 address sends from the device's MAC-48 address to FF-FF-FF-FF-FF-FF (broadcast).
#2: OFFER: 192.168.0.10 says: "I'm a DHCP server. How about using 192.168.0.235?" This is sent back to IP address 0.0.0.0, and sent to the DHCP client's MAC-48 address.
#3: REQUEST: 0.0.0.0 says to 192.168.0.10: "May I have 192.168.0.117?"
(For example, the laptop used 192.168.0.117 before.)
#4: NACK: 192.168.0.10 responds: "No." (Maybe another system is using that now.)
#5: Laptop gives up on being able to continue to use the address it wanted to.
#6: (Perhaps after another DISCOVER and OFFER?) The DHCP client makes another REQUEST. So, using numbers already shown in this example, 0.0.0.0 says to 192.168.0.10: "How about letting me have 192.168.0.235?"
#6: ACK: DHCP server says, "Okay. 192.168.0.235 is reserved for you, for the next 8 hours. Be sure to request a renewal before that time if you want to keep having that address reserved. Otherwise, I might give out that address to someone else."
So that demonstrates another benefit we have, thanks to the REQUEST step.
Now, since REQUEST is part of the design, the step really is a required part of the electronic conversation.
The DISCOVER and OFFER and basically conversations about planning. The REQUEST is the actual attempt to get a commitment. Nothing is actually committed until the ACK is made. A DHCP server could legitimately OFFER the same address to multiple machines, as long as it only ACKnowledges assignment of the address to just one machine. (I'm not saying that there'd be a good reason for a DHCP server to do that. I'm just saying the protocol/standard would allow for that without causing IP address conflicts.) The client is not allowed to use the address until it gets the ACKnowledgement, which only comes after the REQUEST. A DHCP server would not bother sending an ACKnowledgement before a REQUEST, because the typical DHCP client would not be ready for the ACKnowledgement until after it sends the REQUEST, so the typical DHCP client would ignore and miss the unexpected ACKnowledgement.
