30

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 ?

Machavity
  • 111
  • 10
guidev
  • 541
  • 1
  • 5
  • 15
  • 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 07 '20 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 08 '20 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 09 '20 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 '20 at 07:08
  • Although tcp today is usually associated with http and ssl/tls encryption and security which adds overhead but is actually independent, just they are typically associated. – marshal craft Jan 10 '20 at 07:10
  • Also network address translation a critical aspect of modern internet gets hairy with udp. Because tcp uses a notion of a unidirectional connection or one way connection. Which is always initiated by the client on the subnet. So outside servers can only talk ounce called. Udp has no notion and so there can be issue with udp. – marshal craft Jan 10 '20 at 07:14
  • 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 '20 at 07:38
  • @Ron Maupin I'm not gonna lawyer this on the exact verbage used. Wikipedia on top main article as of me writing this seems to be in disagreement and def does use the words client and server. It is not unidirectional in a true sense however the connection is orientated. I admit my comment could of been missleading but then again were not talking about electrical engineering serial hardware network. – marshal craft Jan 11 '20 at 22:41
  • My point is, a _server_ provides a _service_ at the application layer, and a client consumes that service. TCP does not have that concept. Despite what I keep hearing about a Unix programming book that says a client contacts a server, but never the other way around, that is simply incorrect. That is true for pull applications, but not push applications. We have servers that regularly contact the user client PCs to push updates or check on something. Those servers initiate the TCP connection, but they are _servers_ providing a _service_, not clients consuming a service. – Ron Maupin Jan 11 '20 at 23:57
  • @marshalcraft, in fact, if you look at how a TCP connection is established, _both_ sides need to send a SYN, and _both_ sides need to ACK the SYN from the other side for the connection to be established. If one side was in charge, then there are other methods. Each side of a TCP connection is an equal peer of the other side. Both sides can send and receive, even simultaneously, neither side controls the other side, and either side can terminate the connection at will. – Ron Maupin Jan 12 '20 at 00:08
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer. – Ron Maupin Dec 17 '20 at 14:39

8 Answers8

80

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.

Jonathon Reinhart
  • 105
  • 5
Mario Jost
  • 1,690
  • 8
  • 20
  • 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 08 '20 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 09 '20 at 09:32
  • 1
    @jonathanjo Not only that. It is possible that the IP address the client has isn't even valid anymore. – Tonny Jan 09 '20 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.

Ron Trunk
  • 66,852
  • 5
  • 65
  • 126
  • 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 08 '20 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 08 '20 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 08 '20 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 09 '20 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.

reirab
  • 469
  • 3
  • 7
  • And more round trips for the FINs and ACKs. – user207421 Jan 07 '20 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 07 '20 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

Kevin
  • 91
  • 3
3

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

THARUN REDDY GONNURU
  • 31
  • 1
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.

Zac67
  • 81,287
  • 3
  • 67
  • 131
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.

Ams
  • 1
-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

Sagar Uragonda
  • 835
  • 1
  • 16
  • 73