RE: [dhcwg] ID's: DHCP Discovery Extensions

["Kostur, Andre" <[e-mail]>]

> > -----Ursprüngliche Nachricht-----
> > Von:	Kostur, Andre [SMTP:[e-mail]]
> > Gesendet am:	Dienstag, 4. November 2003 00:15
> > An:	'Rentschler, Markus'; [e-mail]
> > Betreff:	RE: [dhcwg] ID's: DHCP Discovery Extensions / Interface
> > Informati on Option
> > 
> 	.... 
> 
> > Regarding: DHCP Discovery Extensions 
> > 
> > - I think there's some overlap here.  What's different between a
> > DHCPCONFIGURE, and a DHCPRECONFIGURE (RFC 3203) 
> (Functionally speaking).
> > Both of them cause a device to acquire new configuration 
> information.
> 	[MR>]  
> 	To use DHCPFORCERENEW (DHCPRECONFIGURE), the client must already
> have a lease assigned!

True, the device must already have a DHCP state machine running.  But if
there's no state machine running, then the device is choosing to not use
DHCP!

> 	With the Discovery Extensions I try to overcome this. 
> 	It's in fact a different philosophy to "traditional" 
> DHCP, even a
> different protocol, that just uses the DHCP packet format and the DHCP
> infrastructure!! This point must be clearly understood.

So you're trying to say that this draft only pertains to unconfigured
devices?  And that DHCP servers should be extended to hold information about
devices that aren't performing DHCP (If it is performing DHCP, then the
server will learn about the device when it Discovers....)?  (Are we then
duplicating effort with other protocols/applications which deal with the
network discovery stuff such as SNMP workstations?)
 
> 	Right now there are some proprietary Discovery Protocols under
> development by some industry consortiums that go into that direction.
> 	But I don't want yet another proprietary packet format 
> and protocol
> infrastructure if I can easily adopt DHCP, which does familiar things
> anyway. Thats the background of my draft.

OK, but DHCP isn't a device discovery protocol (and IMHO, shouldn't be.  And
devices which are configured to be using DHCP will, at some point, broadcast
Discover, at which point the device will be "discovered").  And there is at
least one other "Discovery Protocol" mechanism that would work almost as
well (using existing protocols)... performing ICMP Echos to determine if
there is a device, followed by performing an SNMP Walk on the target device.
(Note that later on you mention a target environment of a factory floor, so
we wouldn't need to worry about firewalls getting in the way....)

> > - The DHCP Client behaviour talks about an "initially 
> granting server",
> > what if the device has not yet been granted a lease from any server?
> 	[MR>]  See my point above. In that case it is configuration, not
> reconfiguration! 
> 	Reconfiguration should be restricted to the initially granting
> server, but not configuration.

But then the draft is confusing.  The draft talks about an initially
granting server (thus the device already has a lease), and you're talking
about configuration (thus the device has no initially granting server)....

> > - I don't think this draft really takes into consideration 
> the scope of
> > where DHCP is used.  According to the draft, a DHCPNETSCAN may be
> > broadcast, and should be relayed onto all other subnets.  Thus if a
> > central DHCP server emits 1 of these messages, that will 
> result in it
> > being broadcast to _everything_ on an entire intranet.  And 
> what about
> > relays behind relays?  What about relays that aren't on the 
> same subnet as
> > the originating server?  And then there's the problem of potentially
> > hundreds of thousands of devices _all_ trying to DHCPREPORT 
> back to the
> > server within a 2 second timeframe!
> 	[MR>]  For this reason I propose to make this mechanism
> (Broadcasting over relays) configurable. Then it's entirely in the
> responsibility of the network administrator, if he wants to take the
> potential risk having his network flooded with broadcasts.I see the
> application of the discovery mechanism mainly in networks that run on
> factory floors, which are not publicly accessible and consist 
> of lets say a
> maximum of ten thousand devices.

Sure it's configurable.  But your draft sets it up in the default case that
"A broadcasted DHCPNETSCAN message SHOULD be broadcasted into a relay
agent's other subnets."  (Actually, I just noticed that by default the draft
wants all REPORTs to be broadcast too... so that one DHCPNETSCAN which is
sent across your network results in potentially everybody on your network
broadcasting back to you.... now there's an efficient DDoS attack on your
entire DHCP infrastructure!)

> 	I also proposed in my draft to restrict broadcasting to certain
> relay interfaces, using the giaddr-field and/or the relay 
> agent information
> option. I think this would be very useful for security reasons and
> scalability (the server will be able to scan subnet for 
> subnet or interface
> for interface)
> 
> 
> > - DHCPREPORT says that option 61 is to be supplied.  There is no
> > requirement that a client _has_ a clientID.  It also says 
> that option 3 is
> > to be supplied too.  A device may not have a router defined.
> 	[MR>]  "The client MUST omit any parameters it cannot 
> provide." (see
> chapter 5). This should of course also be mentioned in chapter 3.3.

You may wish to reword that to something along the lines of "these options
are required to be sent by the client, all other options MAY (MUST?) be
included if the client has pertinent information".

> > - DHCPCONFIGURE is very disruptive to the network.  If all the
> > administrator changed was the client's DNS settings (for 
> example), this
> > draft requires the client to RELEASE it's existing lease, 
> and then assume
> > the new settings. 
> 	[MR>]  The Discovery Extensions rely heavily on the server. The
> people that implement and/or operate the server need to know 
> what they are
> doing. Of course can misuse of he server disrupt the network. 
> I can' t see
> any other strategy to prevent that than firing the admin if 
> he misuses the
> server under his control ;-)).
> 
> >  It's a little foggy as to what the DHCP server is going to 
> do when it
> > receives this RELEASE message.  
> 	[MR>]  Standard RFC2131 behaviour: The server has to check its
> internal lease database and relase that lease. 
> 	Sending a RELEASE is mainly for backward compatibility 
> with RFC 2131
> if there is a server on the network that doesn't support the discovery
> extensions.
> 
> > The draft also doesn't specify what order the RELEASE and 
> REPORT are to be
> > sent in.
> 	[MR>]  First RELEASE then REPORT.

OK, what happens in the case:

1) Device A sends the RELEASE
2) Device B Discovers & Requests (since the IP is now available, it was just
released!) the now released IP
3) Device A REPORTs on that IP

?

> > - In section 3 you state: "To existing correct 
> implementations of BOOTP
> > relay agents these new message types SHOULD be 
> transparent."  This is
> > incorrect.  For DHCPNETSCAN (A server-to-client message), 
> the bootp relay
> > agent is supposed to broadcast that message on all connected subnets
> > (except the one it was received on).  This is not the 
> "normal" behaviour
> > of a relay agent.
> 	[MR>]  This describes the desired extended behaviour 
> defined in my
> draft. An existing relay agent that does not support the 
> discovery extension
> should never broadcast the DHCPNETSCAN packet. 
> 
> > In the abstact these are the stated goals: 
> >    - Discovery of clients in the network 
> >    - DHCP server redundancy 
> >    - Server-initiated configuration of clients 
> > 
> > DHCP server redundancy is already covered in the Failover draft.
> 	[MR>]  This is true. But server redundancy is not the 
> main purpose
> of the discovery extension. It's a nice "side-effect" and 
> IMHO much less

Not to sound nasty, but if this isn't a purpose of the discovery extension,
why is it stated as a goal of the draft?

> complicated than the failover protocol. But server redundancy 
> only works
> with clients that are able to broadcast DHCPREPORT messages. 
> It will not
> work with old BOOTP and DHCP clients, since they are unable 
> to tell other
> servers about their configuration.
> 
> >   Server-initiated configuration is covered in RFC 3203.  
> I'm not sure
> > that this draft can even do the Discovery of clients in the 
> network, as
> > any device which doesn't perform DHCP would be completely 
> invisible to
> > this scheme (as would any device which doesn't implement 
> this draft).
> 	[MR>]  For not beeing invisible, a device needs at least to be
> capable of BOOTP or DHCP, since they tell the server "Hey, 
> I'm here!".  For
> silent discovery, the clients of course need to be capable of 
> the Discovery
> Extensions.


Another general comment about the draft.  Offhand I think the DHCPCONFIGURE
message is superfluous when there exists RFC 3203.  I don't see anything
that that DHCPCONFIGURE does that DHCPRECONFIGURE can't do.  In the case of
an "unconfigured" client, there's nothing that needs to be done except wait
for the device to naturally Discover.  For an already configured device we
can send a FORCERENEW, and the device will immediately transition to the
Renewing state, causing it to perform a REQUEST/ACK sequence, at which point
the device can reconfigure itself based upon the data in the new ACK packet.