Subject: RE: [dhcwg] An enhancement for DHCPINFORM?

From: "Kostur, Andre" <[email-masked]>
Date: Fri, 8 Apr 2005 07:22:36 -0700

> I just started thinking about using DHCP for automatic 
> configuration of
> proxy addresses and I've hit a problem and come up with a solution.
> 
> The problem is this: suppose I want to use DHCPINFORM to get
> configuration information for an non-privileged, user space 
> application;
> a good example would be a web browser doing WPAD via DHCP.

[snip.  Nutshell version of proposal: assign one flag bit to have the DHCP
server respond to the source port of the incoming INFORM instead of 67]

A few questions to ponder:

1) Would DNS lookup of SRV records be more appropriate?  Kerberos uses this
mechanism, for example.
2) Does your DHCP client already put the returned data somewhere where your
application could access the information, so you could simply read what your
original response was?  Perhaps a dhcpcd.eth0.leases file (Linux?) or the
registry (Win)
3) Does your DHCP client has some sort of provision where you could ask it
to perform the INFORM on your behalf and return you the data?
4) How much effort is it going to be on the part of the DHCP Relay
implementations to have to remember the source port of the request, and to
match up the response to the right request.  Recall that what would end up
happening (potentially) is that your client application may broadcast the
request (from say port 2000).  This gets picked up by a relay, and it
unicasts to the DHCP server (likely a different port than 2000, probably
either 67 or 68).  The DHCP server would then see this bit set and would be
"forced" to respond to the source port (again: either 67 or 68, depending on
your relay implmenetation.  Most signficantly it will probably not be 2000).
Then the relay would need to have enough memory to recall that this response
is associated with a certain request and look up what the original port
number was.  In addition, it would have to remember this port for a time
since the relay may be relaying to multiple DHCP services and you would want
all potential responses to be forwarded back to the client.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Simon Kelley <[email-masked]>
Date: Fri, 08 Apr 2005 16:19:56 +0100

> A few questions to ponder:
Good ones, too.

> 
> 1) Would DNS lookup of SRV records be more appropriate?  Kerberos uses 
> this mechanism, for example.
Possibly, but DHCP does have this functionality too, and it would be 
nice to have it usable. There may well be installations which have the 
ability to configure a DHCP server, but not generate private DNS zones.

> 2) Does your DHCP client already put the returned data somewhere where 
> your application could access the information, so you could simply read 
> what your original response was?  Perhaps a dhcpcd.eth0.leases file 
> (Linux?) or the registry (Win)
All the DHCP clients I know do that for a very common subset of 
configuration (DNS servers, NTP servers, maybe YP servers.) The problem 
is that to build in support for a new service, for example 
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-dhc-proxyserver-opt-03.txt 
both the clients using the service _and_ the DHCP client have to be 
upgraded. By allowing the clients which need the information to do the 
DHCPINFORM query themselves, collateral changes to the DHCP client are 
avoided.

> 
> 3) Does your DHCP client has some sort of provision where you could ask 
> it to perform the INFORM on your behalf and return you the data?
That's a good second best. The main objection is that on Unix-like 
systems, there is no standardisation of DHCP clients, so a browser (for 
instance) wanting to do that would either have to mandate use with a 
particular DHCP client, or have redundant support for many DHCP clients.

> implementations to have to remember the source port of the request, and 
> to match up the response to the right request.  Recall that what would 
> end up happening (potentially) is that your client application may 
> broadcast the request (from say port 2000).  This gets picked up by a 
> relay, and it unicasts to the DHCP server (likely a different port than 
> 2000, probably either 67 or 68).  The DHCP server would then see this 
> bit set and would be "forced" to respond to the source port (again: 
> either 67 or 68, depending on your relay implmenetation.  Most 
> signficantly it will probably not be 2000).  Then the relay would need 
> to have enough memory to recall that this response is associated with a 
> certain request and look up what the original port number was.  In 
> addition, it would have to remember this port for a time since the relay 
> may be relaying to multiple DHCP services and you would want all 
> potential responses to be forwarded back to the client.
> 

I think it would be fine to specify that the flag is only valid in DHCP 
requests which are unicast directly to a DHCP server, so there should be 
no implications for relay agents.

Cheers,

Simon.

---

From: Robert Elz <[email-masked]>
Date: Fri, 08 Apr 2005 23:19:20 +0700

Date:        Fri, 08 Apr 2005 16:19:56 +0100
    From:        Simon Kelley <[email-masked]>
    Message-ID:  <[email-masked]>

  | That's a good second best. The main objection is that on Unix-like 
  | systems, there is no standardisation of DHCP clients, so a browser (for 
  | instance) wanting to do that would either have to mandate use with a 
  | particular DHCP client, or have redundant support for many DHCP clients.

You're planning on (suggesting) standardising something new.   Why not
standardise that (the DHCP client to application interface), instead of
a new DHCP option bit (or a new way of operating DHCP servers)?
Is it really that much harder to deal with POSIX instead of IETF?

The result would be much better - and could provide all that's necessary
to ask for an option, and get the result, without the DHCP client needing
to have any idea at all what any of it means - which avoids the problem of
needing to upgrade the DHCP client to get any new data (which currently
is really only required so the DHCP client knows what to do with the new
data when it arrives - requesting something new should not require client
upgrades, if it does, the client is already deficient and needs upgrading).

kre

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 8 Apr 2005 10:11:19 -0700

> DHCPINFORM query themselves, collateral changes to the DHCP client are 

how would the got-by-INFORM values be expired as changes are made?  do
you intend to track this with the dhcp client's lease times?  what if you
roam between networks and that cache data becomes invalid?

i think there could be advantages to asking applications make such
requests through a layer the dhcp client controls - it could make
informs for new options, and remember to put it on the requested
options list in future renewals or reboots.

> no implications for relay agents.

then you're back to redundant support for multiple dhcp clients in
order to divine what the dhcp server's ip address is.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Apr 2005 10:20:00 -0700

> Is it really that much harder to deal with POSIX instead of IETF?

Robert wins the prize here for the best suggestion so far.   :')

---

From: Simon Kelley <[email-masked]>
Date: Sun, 10 Apr 2005 15:56:28 +0100

> Robert wins the prize here for the best suggestion so far.   :')

Agreed: this looks like my best option. I'm not sure about POSIX, but I 
found that the people at freedesktop.org are starting to think along 
these lines. The NetworkManager project is playing in the correct space, 
and I guess that eventually they will get around to supplying a set of 
methods to query arbitrary network configuration over the D-bus.

Clearly, this is likely to happen before a DHCP server spec change could 
be made and rolled out to  a substantial proportion of the world's DHCP 
servers. I shall take my stall over there and see where I can help.

In the meantime, I would suggest that there's nothing to be lost (except 
one bit in the flags field) in adopting my suggestion, next time the 
DHCP spec is updated. Please remember me then!

Thanks for all the helpful suggestions.

Cheers,

Simon.