Can Dhcp client receive messages on a different port than 68?

Shane Kerr Shane_Kerr at
Wed Jul 19 13:15:56 UTC 2006

Hash: SHA1


Lilian JS wrote:
> Hello!
> RFC says that client should send to server port 67 and
> server should send to client port 68. I would like to
> know whether the client can receive on another
> port?..And if the client can, will it be
> inter-operable with the other servers out there? Does
> the server always send to the default client port, or
> on the port from which the client message came?

With the ISC DHCP client, you can specify alternate ports to use. This
is a command-line option, for example:

dhclient -p 6668

The client binds to the port specified, and sends to 1 less. In this
case, the client would send to 6667 and receive on 6668.

AFAIK this is not standardized anywhere.

The DHCP standard specifies where packets are sent to. Because of this,
we cannot do like other protocols, and send packets back to the port
where they originated. The standard does *not* specify where the packets
are sent *from*.

So, a client may bind to port 68 to receive messages, but send messages
to the server port 67 *from* port 9999. If the server replied to port
9999, the client will never receive the answers.

I have thought about an option to allow a client (or relay) to tell the
server to reply to a different port, but I don't know if it would be
generally useful. I don't think that such an option would be useful for
a server, since client/server interaction is started by the client.
(Even in the case of a unrequested lease revocation, the server has
already talked to the client.)

- --
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the dhcp-users mailing list