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

From: "Kostur, Andre" <[email-masked]>
Date: Mon, 19 Mar 2001 10:03:03 -0800

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: [email-masked]
Date: Wed, 21 Mar 2001 10:29:40 -0000

[>]   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. 
	[>]  

	I think it boils down to implementation. For instance they could
have a kernel network driver that sits just above the network card, but
below ip, that snifs dhcp traffic ( well known port). This could be wrapped
in a com object at the application layer that can then acts as provider of
dhcp traffic/signals for other objects, get address object, renew object,
reconfigure ..... In that case a single port makes sense.

	nick

---

From: [email-masked]
Date: Wed, 21 Mar 2001 11:33:27 -0800

I don't understand this issue.  Applications don't renew an address.
Applications don't usually know anything about how an address (or any other
IP parameter) was assigned: static, manual, DHCP, IPCP, etc.  I don't see
any reason for an application to use the DHCP port.
-------------------------------------------
Eric L. Michelsen, Copper Mountain Networks

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2001 2:30
> To: DHCPv4 discussion list
> Subject: RE: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-02.txt
> 
> 
>

---

From: [email-masked]
Date: Wed, 21 Mar 2001 11:47:26 -0800

That's a plausible scenario (but notably different from the one discussed
below about "applications renewing an IP address").  While plausible,
though, it seems pretty rare to me.

I guess the question is: how much restriction do we allow in the protocol
development to accomodate limited implementations of the past that might or
might not be deployed?
-------------------------------------------
Eric L. Michelsen, Copper Mountain Networks

> From: Kostur, Andre [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2001 11:47
> To: Eric Michelsen; DHCPv4 discussion list
> Hey Eric :)
> What about application software on the device which needs 
> data from the DHCP
> Options list which aren't recognized by the DHCP Client 
> software on the box.
> Couldn't such software emit a DHCPINFORM packet to the DHCP 
> server to get
> the set of options back, and parse out the options of interest to the
> application?  Now this does assume that the DHCP client 
> software doesn't put
> the complete set of options that it received from the DHCP 
> server into a
> location where other applications may retrieve the data.  If 
> the client
> software only keeps the options of interest to it, then the 
> other data would
> be lost.
> 
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2001 11:33 AM