InformIT published a great article describing the way DHCP works. I reproduced below the 3 steps mecanism used to provide an IP address to a client:

1. Like any process in computing, the DHCP resolution process is initiated by the client. It’s looking for an IP address, and probably since the system has just been booted, it doesn’t have one yet. So it broadcasts a message called DHCPDISCOVER throughout the network to all points, by way of sending a packet to destination address 255.255.255.255. This particular message is like a cry of a newborn chick calling for its mother…except that it’s using a prescribed protocol (specifically, it’s flagged for UDP port 68), and lacks all the gooey platitudes that come with poorly written children’s books.
2. The DHCP server responds to the caller (using its physical or MAC address, since it doesn’t have an IP address at this point) with a DHCPOFFER message. Here, the server is acting like a car dealer negotiating the terms of a lease. It hands the client a prospective address (which it shouldn’t have reason to turn down), plus the physical and IP addresses of the DHCP server—or, more technically, the server running the DHCP server software—plus the new IP address and subnet mask as an offer to the client. If multiple DHCP servers responded to the original cry for help, the client is likely to respond “yes” to the first DHCPOFFER it receives.
3. The client responds with a DHCPREQUEST message, which by name might make you think it comes first. Actually, this is a request essentially to all DHCP servers that responded with a DHCPOFFER, saying it accepts the offer from the first server to respond to the DHCPDISCOVER message. The other servers can now discontinue reserving the IP address they had reserved.