In most client-server-applications, the port number of a server is a well-known number, while the client uses a currently available port number. DHCP is different. Here, both the client and the server use a well-known port: UDP port 67 for the DHCP server, and UDP port 68 for the DHCP client.
Does anybody know the reason why this protocol design was chosen? Why should a DHCP client also listen on a well-known port?
I will appreciate any kind of responses.
Thanks for geeking. 
DHCP is a UDP service. So there are no connections and there is no “listening”. So you need different source ports to identify whether the packet comes from a server or a client.
With a TCP service there are also two ports. It’s just that one of the ports is usually a random high port selected by the client so you don’t normally think about this port.
server will always have the port number from where it gets the packet so this can not be the right answer,
this requirement might be put on so that there can be only one dhcp client instance running at a time.
Thanks
devesh
If you want to research your question, it’s almost certainly in one of the RFC at ietf.org.
A list of DHCP related RFC in chronological order
Appendix C: DHCP RFCs
I hadn’t thought much of this, but DHCP is fundamentally a broadcact protocol (cannot be UDP or TCP because the client does not yet have an assigned address) so it would make sense that kind of traffic should be configured so it would only be listened to, depending on whether the Host is a DHCP server, Host without an address (but identifiable by MAC address) or ignored because the Host already has an IP address.
TSU
On 03/07/2013 04:26 AM, tsu2 wrote:
> I hadn’t thought much of this, but DHCP is fundamentally a broadcact
> protocol (cannot be UDP or TCP because the client does not yet have an
> assigned address) so it would make sense that kind of traffic should be
No, part of that is not true. While TCP and IP are almost always used
together (other than when UDP and IP are together) they do not require one
another and are on different layers of the OSI model (IP is layer three,
TCP and UDP are layer four). DHCP does use ports, specifically 67 and 68
as mentioned earlier and as can be seen in /etc/services on any old box.
Just because something does not have an IP address does not mean there
cannot be some other protocol at layer three doing the work. Really all
intra-broadcast-domain (intra-network) traffic “routes” (or gets switched
or broadcasted) via MAC addresses alone, not IP address, from one host to
another, so in that case while the IP address was used to “resolve” to the
MAC address, the most-important part for traffic delivery is just the MAC
address, or else DHCP/bootp would never work (how could it? no IP
address, as you mentioned).
Going up to the post to which you responded by devesh2408, there are some
errors there too. The first post that I can see (via NNTP… this thread
is too old to show the entire thing in my newsreader for some reason) from
ken_yap has ‘So there are no connections and there is no “listening”’
which is half-true… there are no “connections” in the TCP sense
(meaning there will never be a connection showing up in ‘ss’ or ‘netstat’
but there is, of course, listening, and that does show up in ‘ss’ or
‘netstat’. /usr/sbin/ss -au or netstat -anu will show the same stuff.
With all of that said, I cannot figure out what the original point of this
thread was, so hopefully those corrections help in some way. The rest
seems to be in order, and I’ll toss out that there is a dhcpcd-test
command that is pretty useful for troubleshooting DHCP stuff when you box
already has an address and you just want to test the server:
Good luck.
Interesting, trying to parse what you are describing.
I agree with all you said that I can understand, but am trying to identify exactly what I might have described that was incorrect so I can correct my own understandings about “how things are.”
By default, the DHCP bootp protocol is broadcast only (by default cannot pass routers, in those cases a DHCP Proxy would need to be setup), and should pass through switches (Someone might block, but I can’t think why). As you describe, IP can and does exist without TCP (and AFAIK UDP is defined mostly as the absence of TCP but does require source and destination IP addresses unlike broadcasts and so is also routable).
Now, getting back to the OP my speculation is that because broadcasts are very bad on a network (can eat up machine resources if machines process network info not intended for them), a simple way to minimize machine resource usage is to simply listen to a port or not. Once a machine has an IP address, it can simply ignore anything that arrives on that port, blocking at the lowest levels of the OSI layers.
As for the role of the MAC address, I might go off-topic a bit in saying that AFAIK all networked devices actually fundamentally identify each other <only> using the MAC address and not just for "intra-domain switching"and not as you might be suggesting when an IP address is not available. IP addressing is a convenient mechanism humans created to better understand and manage the goings-on at the lower MAC level In other words, although we humans use IP addressing, machines will <always> translate IP addresses to the underlying MAC address when actually doing work.
Still geeking,
TSU
While I appreciate this thread is an old one I just wanted to add some insights into DHCP and broadcast.
DHCP messages are only broadcast during the INIT and REBIND state. If the client is on the same subnet as the server it is only the DHCP DISCOVER and REQUEST messages that are broadcast from the client to the DHCP server.
While it’s true that the Client has no layer 3 address until the DHCP ACK is received the DHCP OFFER and ACK are both sent unicast, the client passes it’s MAC (layer 2) address as part of the DHCP DISCOVER message so the server knows which device it is sending the message back to when it sends the offer and it also uses the layer 3 address it is offering as the destination address.
When the time comes to try and renew the lease at time T1 the client unucasts it’s DHCP REQUEST to the server that allocated it’s address, it only switches to broadcast if it does not get a response to that at time T2.
Raven68