Subject: RE: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 19 Mar 2001 12:15:01 -0600

Yes, I believe that is correct. Is sharing the DHCP port really that useful and usual? It would be very difficult to predict when any of several clients might need to renew an address and thus sharing this port is problematic. Of course, it all depends on how robust you client software is and what it does if the port is in use (it might not even know that depending on the socket calls used and the implementation).

If you also have multiple client programs running, only one would get the reconfigure event UNLESS you had some communication between the client & server to select the port on which reconfigures would be received.

I think the general view is that you have ONE DHCP client application.

An alternative might be to have the reconfigure sent to new well-known port and then a reconfigure client could be developed that used an O/S specific mannor to distribute the messages. But is this worth it?

- Bernie Volz

-----Original Message-----
From: Kostur, Andre [mailto:[email-masked]]
Sent: Monday, March 19, 2001 1:03 PM
To: DHCPv4 discussion list
Subject: RE: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt

If I understand the draft correctly, implementation of this draft on client
devices would require the DHCP client software to be permanently bound the
DHCP client port on the device to listen for incoming DHCPReconfigure
messages.  Wouldn't this have the implication that other pieces of software
on the device would not be able to send DHCP messages (and expect a
response)?  For example, a client device could not be on DHCP and still have
some other piece of software which wants to get some configuration
information by emitting DHCPINFORM packets since both the DHCP client, and
this other software can't both be bound to the DHCP client port?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Mar 2001 14:24:43 -0600

> Is sharing the DHCP port really that useful and usual? It would be
> very difficult to predict when any of several clients might need to
> renew an address and thus sharing this port is problematic.

I believe this is how Microsoft currently does things.  It's perfectly
legitimate, although I have to admit that I was rather surprised to
learn they'd done it that way - to me it makes more sense to have one
client that talks to the wire and provide an API for other programs to
use.  Aside from allocating a new port, which I think is not a great
idea, I don't see any way to solve this problem.

			       _MelloN_