DHCP uses UDP as its transport protocol. DHCP messages that a client sends to a server are sent to well-known port 67 (UDP—Bootstrap Protocol and DHCP). DHCP Messages that a server sends to a client are sent to port 68, so can DHCP use TCP ?
DHCP cannot use TCP as the transport protocol because TCP requires both end-points to have unique IP addresses. At the time a host is required to use DHCP, it does not have an IP address it can source the packets from, nor does it have the IP address of the DHCP server. So it uses
0.0.0.0 as the source IP address and
255.255.255.255 (broadcast) as the destination IP address (this is for DHCP - similar behaviour is present for DHCPv6). These IP addresses are not valid host IP addresses and can be used by multiple clients at any time. So a TCP connection wouln't be "unique" for lack of a better term.
Since the source has no IP address (0.0.0.0) and the destination is everyone (255.255.255.255), it's hard to see how you would identify a particular session. But even if you could, what would be the benefit? The data in a DHCP message is quite small (~300 bytes), so it can easily fit into a single segment. It's not worth the overhead to establish a TCP session.
The point of UDP is for application data that is simple enough not to require the reliability and flow control of TCP. DHCP is a good example of that.
There are multiple reasons why TCP wouldn't work for DHCP(v4.)
First of all, TCP is connection-oriented. A TCP connection is defined between two particular hosts. However, when a DHCP client first starts up, it doesn't know which host(s) it wants to talk to. Its only option is to broadcast a DHCP DISCOVER message to all hosts on the local network. Broadcasting is inherently incompatible with TCP's connection-oriented nature, since it's not a 1:1 relationship. Since DHCP is inherently connectionless, UDP makes more sense.
Second, the DHCP client does not have an IP address assigned until the DHCP process is complete. Even if the DHCP client already knew the particular DHCP server it wanted to request an address from (which is typically doesn't) and knew its IP address, it would not be able to open a TCP connection with it because the client doesn't have an IP address yet for the server to respond back to. By the time the client does have an assigned IP address, DHCP's job is already complete.
Third, while not nearly as fundamentally important as the above issues, avoiding TCP also reduces the number of required round-trips by one. A typical DHCP exchange needs two round-trips: DISCOVER (client->server), OFFER (server->client), REQUEST (client->server), and ACK (server->client). Setting up a TCP connection would require an additional round-trip at the beginning for the TCP SYN and SYN-ACK connection setup messages. Data can't be sent on the TCP connection until the final ACK message of the 3-way TCP handshake.
When the host starts up it has no knowledge of the network addresses or masks that it should use. The only way for it to communicate is via an IP broadcast (255.255.255.255) to the local network. The DHCP client initiates a broadcast request on UDP port 67. The client cannot use TCP because it does not have an IP address of its own, nor does it know the DHCP server address.
The DHCP server is listening for broadcasts on UDP port 67. Once it receives a dhcp client request, it starts the bootp sequence of passing config information to the client using the MAC address of the client.
Once the client has its IP address, gateway, subnet mask, etc assigned, then it can initiate or receive TCP connections.
Hope that helps
Just to add The Real Reason (tm) for using UDP for DHCP: when selecting the best transport protocol for your application you weigh
UDP is simpler, robust enough and more efficient and functional than TCP for DHCP's purpose. It isn't even possible to use TCP as the other answers have sufficiently pointed out - basically, TCP requires a working two-way connection and that's not possible before you've got an IP address.