29

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 ?

Improve this question
11
  • 13
    Remember: unless there is a reason to use TCP, UDP is often preferable over TCP due to UDP having lower overhead. Many protocols that transmit potentially large amounts of data (exceeding one packet) use TCP for simplicity of handling flow control of multiple packets. DNS is like DHCP in that traditional DNS (not involving DNSSEC keys/etc.) most often used UDP because the entire conversation could be over before TCP's overhead would be useful. Instead of the receiving end reporting a request to resend a TCP packet, the client could probably just start a new DHCP request (almost) as efficiently
    – TOOGAM
    Jan 7, 2020 at 23:31
  • 2
    There are two major reasons: one is that DHCP (which is a superset of BOOTP) uses broadcast traffic, and so must be connectionless; the other major reason (historical) is because a TCP/IP stack wouldn't fit in the resource-constrained ROM environment on a network card, whereas UDP/IP did; this is why TFTP is UDP.
    – Cameron Kerr
    Jan 8, 2020 at 20:02
  • 4
    Neither comment is the actual reason, which is because TCP requires unicast IP, which isn't possible if you haven't got an IP address yet.
    – OrangeDog
    Jan 9, 2020 at 15:54
  • Also prob most importantly, tcp is reliable, lossless, protocol but udp is not. So a udp packet is sent and that's it, who knows what happens to it. Where tcp will resend if necessary and the packets must arrive. Some applications don't require this, like real time video or something. If say some pixels are lost well it's too late the show must go on. But other things like bank transaction or something is important and needs to be resent. Then tcp has advantage cause lower osi level handles it, perhaps even hardware. Making it the fastest for lossless.
    – marshal craft
    Jan 10, 2020 at 7:08
  • 4
    @marshalcraft "Because tcp uses a notion of a unidirectional connection or one way connection. Which is always initiated by the client on the subnet." That is simply incorrect. TCP connections are bidirectional between peers. TCP has no notion of clients or servers. The client/server concept is an application concept. On a TCP connection, both ends are equal peers and can send, receive, or even close the connection. The RFC has no mention of clients or servers.
    – Ron Maupin ♦
    Jan 10, 2020 at 7:38

8 Answers 8

Reset to default
78

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.

Improve this answer
3
  • 6
    "required to use DHCP, it does not have an IP" ­— I think in this discussion of protocols it's better to explicitly say "IP address" when you mean the address instead of the protocol.
    – Ruslan
    Jan 8, 2020 at 18:58
  • 1
    Just noting that DHCP also is sometimes used in cases where the client does already have an address. See RFC 2131 sect 3.4. It still uses broadcasts though, as it doesn't necessarily know the address of the DHCP server.
    – jonathanjo
    Jan 9, 2020 at 9:32
  • 1
    @jonathanjo Not only that. It is possible that the IP address the client has isn't even valid anymore.
    – Tonny
    Jan 9, 2020 at 16:26
25

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.

Improve this answer
4
  • 1
    Just a tiny note to add that this is only one point of UDP. Other uses include more-predictable latency than TCP, and easy-to-use broadcast features.
    – jonathanjo
    Jan 8, 2020 at 10:54
  • Another point of UDP is media streaming. If one of the packets gets lost and arrives late there is no point holding up the whole stream for it - just drop it, allow a small glitch in the stream, and carry on with the next packet.
    – Martin Bonner supports Monica
    Jan 8, 2020 at 13:08
  • 7
    @MartinBonnersupportsMonica to be more precise, UDP when streaming really only makes sense for low latency, real time stream. The use case for that is for example video chat and VoIP, for these use cases, you can't buffer ahead the stream and it's better to keep pace with the conversation than to lag behind. For non-low latency, non-real time streaming, for example with video streaming like Youtube, it makes for a better experience if you buffer ahead the media and pause playback if the download wasn't able to keep up rather than skipping frames.
    – Lie Ryan
    Jan 8, 2020 at 13:53
  • Also, you start with "no ip" then end up with a new IP address. How exactly would a TCP connection switch ip addresses? Is that even possible?
    – Katastic Voyage
    Jan 9, 2020 at 19:38
21

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 it 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.

Improve this answer
2
  • And more round trips for the FINs and ACKs.
    – user207421
    Jan 7, 2020 at 22:59
  • 1
    @user207421 Well, an extra half of a round-trip, anyway, but, yeah, that's a good point. Theoretically, the client could send FIN along with DHCPREQUEST and the server could send FIN-ACK along with DHCPACK, but then the client would still need to send a final ACK back to the server to be compliant.
    – reirab
    Jan 7, 2020 at 23:07
7

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

Improve this answer
3

just simple....dhcp uses the broadcasting but we dont have any broadcasting in TCP

Improve this answer
1

Just to add The Real Reason (tm) for using UDP for DHCP: when selecting the best transport protocol for your application you weigh

  • simplicity
  • efficiency
  • robustness
  • functionality

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.

Improve this answer
0

DHCP is an extended version of BOOTP. Bootp allows udp and hence DHCP should have adopted udp from it for the compatability of the devices.

Improve this answer
-1

Udp is not reliable protocal . It has timeframe within this timeframe for given request responce has to receive. Otherwise packet. Is discarded . When client is requesting ip from DHCP server entire D= discover O=offer R=request A=acknowledgement

This entire process should complete us recommended time frame otherwise packet will get discarded . Udp protocol if any drop in packet it won't wait in queue . It will proceed because of this udp features it is used in DHCP , dns , and voice traffic

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.