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?
So, basically, it is normal that port 68 will be "open" as long as your system sees itself as a DHCP Client, i.e. as long as networking is active. It is not really the task of a specific program or protocol to "open" or "close" a port, or to control the traffic going through it.
The DHCP employs a connectionless service model, using the User Datagram Protocol (UDP). It is implemented with two UDP port numbers for its operations which are the same as for the bootstrap protocol (BOOTP). UDP port number 67 is the destination port of a server, and UDP port number 68 is used by the client.
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.
Ports 67 & 68 are normally used for an address assignment from a DHCP server. The client requests configuration on a broadcast to port 68 (bootps). The server broadcasts back the response to port 67 (bootpc). Your scan should show no open ports, and 68 should not be open "out".
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With