Why DHCP client listens on port 68?
Asked Answered
O

3

16

If suppose client does not listen on 68 port,when DHCP server receives the request, it can send it to the address from where it received request (with ephemeral port chosen by client at time of sending), then why does protocol specifies client to be listening on port 68?

Orchid answered 24/11, 2009 at 15:52 Comment(0)
L
3

Because it's in the RFC (Request for Comments) that specifies how DHCP behaves. RFC 2131 is the document that specifies how a DHCP client and server must behave.

See here for more info on DHCP (section 4.1 in particular). See here for info on what the RFCs are.

Leacock answered 24/11, 2009 at 15:56 Comment(5)
The question reads "why does protocol specifies client to be listening on port 68?", so what they are asking seems to be more "why does the RFC say that?"Inappropriate
DHCP is based on the earlier BOOTP protocol which used ports 67 (server) and 68 (client). Why BOOTP used those ports was probably because they were unused by any of the other protocols at the time (SMTP uses 25, FTP uses 21, etc.). While a host usually has a single IP address, it can have thousands of ports. By assigning particular port numbers to specific protocols it was possible for multiple parties to develop standard services and clients. As long as you listened on the right port, you could write your own DHCP client or server.Leacock
Ok means there is no technical reason?Orchid
The technical reason is that if you want your client to be able to hear the response from any normal DHCP server you need to listen on the right port. I guess if you were writing your own DHCP server/client software (or you could configure your server to use a different port) then you could use whatever port you wanted as long as you were not trying to use a port already being used by some other protocol.Leacock
I wonder if "can't bind to port numbers below 1024 as an unprivileged user" has something to do with it.Seymour
B
19

The main reason is that the DHCP server might broadcast the "DHCP offer" on the mac level, instead of sending it unicast to the mac address it had received the request. If the port wasn't constant, some hosts that are listening by chance to the this same random port, will accept the packet to layer 5 - the application layer. In other words, an application will get message from completely different application, not an healthy situation.

Bufford answered 11/3, 2013 at 13:43 Comment(2)
This answer doesn't seem different than the one from 3+ years ago. If you want to add something, consider suggesting an edit to the existing, accepted answer :)Everyplace
Relevant question: Can I safely firewall off this port in a normal setup where an DHCP client is used to obtain IP addresses? I.e. is the might relevant in the real world?Puffin
E
4

I just had to face the same question myself, and after some research, I found the following on the RFC 2131, which describes the DHCP protocol, under section 1.6 Design Goals:

  • DHCP must provide service to existing BOOTP clients

Also on the RFC 951, which describe the BOOTP protocol, we can find the following:

The UDP header contains source and destination port numbers. The BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68) and 'BOOTP server' (67). The client sends requests using 'BOOTP server' as the destination port; this is usually a broadcast. The server sends replies using 'BOOTP client' as the destination port; depending on the kernel or driver facilities in the server, this may or may not be a broadcast (this is explained further in the section titled 'Chicken/Egg issues' below). The reason TWO reserved ports are used, is to avoid 'waking up' and scheduling the BOOTP server daemons, when a bootreply must be broadcast to a client. Since the server and other hosts won't be listening on the 'BOOTP client' port, any such incoming broadcasts will be filtered out at the kernel level. We could not simply allow the client to pick a 'random' port number for the UDP source port field; since the server reply may be broadcast, a randomly chosen port number could confuse other hosts that happened to be listening on that port.

So the answer to the question comes from the above. DHCP clients need to use the UDP port 68, in order for the DHCP to be compatible with the BOOTP protocol and the BOOTP protocol requires a specific port for the client, since BOOTPREPLIES can be broadcasted, and if a random port was chosen for the client, it could result in the confusion of other hosts listening on the same port.

Environmentalist answered 31/5, 2017 at 20:9 Comment(0)
L
3

Because it's in the RFC (Request for Comments) that specifies how DHCP behaves. RFC 2131 is the document that specifies how a DHCP client and server must behave.

See here for more info on DHCP (section 4.1 in particular). See here for info on what the RFCs are.

Leacock answered 24/11, 2009 at 15:56 Comment(5)
The question reads "why does protocol specifies client to be listening on port 68?", so what they are asking seems to be more "why does the RFC say that?"Inappropriate
DHCP is based on the earlier BOOTP protocol which used ports 67 (server) and 68 (client). Why BOOTP used those ports was probably because they were unused by any of the other protocols at the time (SMTP uses 25, FTP uses 21, etc.). While a host usually has a single IP address, it can have thousands of ports. By assigning particular port numbers to specific protocols it was possible for multiple parties to develop standard services and clients. As long as you listened on the right port, you could write your own DHCP client or server.Leacock
Ok means there is no technical reason?Orchid
The technical reason is that if you want your client to be able to hear the response from any normal DHCP server you need to listen on the right port. I guess if you were writing your own DHCP server/client software (or you could configure your server to use a different port) then you could use whatever port you wanted as long as you were not trying to use a port already being used by some other protocol.Leacock
I wonder if "can't bind to port numbers below 1024 as an unprivileged user" has something to do with it.Seymour

© 2022 - 2024 — McMap. All rights reserved.