Subject: RE: [dhcwg] rfc 2131 details

From: "Kostur, Andre" <[email-masked]>
Date: Mon, 13 Oct 2003 05:21:24 -0700

Sounds like there's two possible solutions:

1) DHCPINFORM (RFC 2131).  Useful if the client is trying to solicit
configuration information

2) FORCERENEW (RFC 3202).  Useful for the server to instruct certain clients
that it is time to renew (to get new config info).

The problem with #2 is that it depends on RFC 3118 (of which I don't know
anybody who supports it yet), and client-side support (same problem.. I
don't know any client which supports it).

And... according to the state diagram it seems to show that "unsolicited"
ACKs, NAKs, and OFFERs are ignored while in the bound state.

-----Original Message-----From: Simon Vogl
To: [email-masked]; Ralph Droms
Sent: 10/13/2003 4:10 AM
Subject: [dhcwg] rfc 2131 details

Hi,
I want to asynchronously transmit data from the dhcp server
to interested clients. The state diagram in rfc2131(Fig.5)
indicates potentially arriving DHCPACKs in BOUND state, which
I could use for transmitting the option values.

Unfortunately, appropriate handling is not defined (or I could
not find it) in this document - is this defined in a newer rfc?

If nothing else is proposed, I'd set the xid to the client ip
address to transmit my dhcp options to be compatible with the
handling of acks in REBINDING state. Is this an acceptable solution?

---

From: Simon Vogl <[email-masked]>
Date: Mon, 13 Oct 2003 14:36:30 +0200

> configuration information
Right, I would use this to get information to the server. Unfortunately,
I need the other direction as well.

> 2) FORCERENEW (RFC 3202).  Useful for the server to instruct certain 
> clients that it is time to renew (to get new config info).
> 
> The problem with #2 is that it depends on RFC 3118 (of which I don't 
> know anybody who supports it yet), and client-side support (same 
> problem.. I don't know any client which supports it).
> 
> 
Yet another: I don't want to change the IP settings on the client, but
only transmit additional data. Forcing the client into Renewing results in
more overhead (# of packets xmited) than simply sending an ACK.

> And... according to the state diagram it seems to show that 
> "unsolicited" ACKs, NAKs, and OFFERs are ignored while in the bound state.
> 
Right, but all I want is a specific option value. So I could go ahead and
parse the options anyway, maybe with the limitation that all other parameters
must match the values the client agreed on earlier.

The sending of packets from server to client depends on a parameter value
(235 in my local setting), so only 'enabled' clients would get additional
packets anyway. If the default is to ignore them, all other implementations
should be able to live with this solution even if they got such a packet.

Simon

-- 
------------------------------------------------
Dr. Simon Vogl
Department  of   Computer  Science
Johannes Kepler University of Linz
Altenberger Straße 69
A-4040 Linz - Austria

Tel: +43 70 2468 8517  [email-masked]
Fax: +43 70 2468 8426   www.soft.uni-linz.ac.at

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Barr Hibbs" <[email-masked]>
Date: Mon, 13 Oct 2003 18:50:52 -0700

comments in-line

--Barr

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Simon Vogl
> Sent: Monday, October 13, 2003 05:36
> To: Kostur, Andre
> Cc: [email-masked] '
> 
> Kostur, Andre wrote:
...DHCPINFORM is a "request" by the client to the server to supply additional option data -- the parameter request list is explicitly allowed so that the client may request a specific set of parameters.  The DHCP server is NOT REQUIRED to process arbitrary options sent by the client as part of the DHCPINFORM message, so your statement "...to get information to the server" isn't quite correct -- the specific behavior of a particular server depends on its implementation, which is not specified by RFC 2131.  The DHCPACK message, returned from the server to the client, does precisely what you wish, that is, sends data from the server to the client.

*Snip!*

> more overhead (# of packets xmited) than simply sending an ACK.
...not necessary:  the pair of messages DHCPINFORM and DHCPACK occurs while the client is in the BOUND state.

> > "unsolicited" ACKs, NAKs, and OFFERs are ignored while in the 
...yes, discarding DHCPOFFERs, DHCPNAKs, and "unsolicited" DHCPACKs is the correct behavior for a DHCP client -- the DHCPACK message received in response to a DHCPINFORM message is NOT an unsolicited message, and SHOULD be processed by the client.

> must match the values the client agreed on earlier.
...precisely!  There has been a great deal of discussion about what to do if options differ between DHCPOFFER and DHCPACK messages, though that discussion did not specifically consider a DHCPACK received in response to a DHCPINFORM message -- if the parameter request list in the DHCPINFORM message only requests the options of interest (note that it CANNOT request a new IP address) then your client implementation is probably generally interoperable.

*Snip!*

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Oct 2003 22:03:49 -0700

Just to stick my two cents in here, you really don't want a DHCP client 
that listens to a DHCPACK when it's not expecting one, since this makes 
it really easy to attack the client and inject a bogus configuration.   
So unfortunately, if you want to do what you want to do, DHCPFORCERENEW 
is probably the way to do it.   :'}

---

From: Simon Vogl <[email-masked]>
Date: Tue, 14 Oct 2003 08:45:25 +0200

Hi and thanks for your insightful comments.

To clear things up a bit: My application is a location based service, that
feeds data to different services on the client depending where he is (location
detected, for example, by moving from one WLAN access point to another).

As the client (program/device) does not know in advance when this location change
occurs, I am looking for a way to submit information to it without implementing
another protocol stack, so simpler devices can be incorporated as well.

> --Barr

<.../>

> 
> ...DHCPINFORM is a "request" by the client to the server to supply additional option data -- the parameter request list is explicitly allowed so that the client may request a specific set of parameters.  The DHCP serrver is NOT REQUIRED to process arbitrary options sent by the client as part of the DHCPINFORM message, so your statement "...to get information to the server" isn't quite correct -- the specific behavior of a particular server depends on its implementation, which is not specified by RFC 2131.  The DHCPACK message, returned from the server to the client, does precisely what you wish, that is, sends data from the server to the client.
> 
> *Snip!*
> 
> 
> 
right in this case, but as stated above: there is no inform msg prior to the ack...
Oh, another idea arises: There is no timeout specified, if I read the rfc right,
between the sending and the reception of the ack to an inform message - so the client
could 'register' for the next location change message that would arrive eventually in
the corresponding ack.

The downside of this idea: It has an inherent race condition as location changes may be
lost as they go by unnoticed when the server has not yet received the next INFORM
(a problem I encountered often when dealing with tuple spaces, but thats a different story).

>>>"unsolicited" ACKs, NAKs, and OFFERs are ignored while in the 
>>
>>bound state.
>>

Yes, I feared that I would bring up old flamewars with this proposal. My client code
would react like this: It ignores any IP settings but searches only for the location-
information option. If this information is found, it is extracted and passed on to the
service management scripts.

The code explicitely blocks any other information found in the dhcp message, if not,
there would not only be severe security problems but also race conditions when there
is more than one dhcp server in the net, I fear.

Thanks for your comments,
Simon