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

["Rentschler, Markus" <[e-mail]>]

Hello Andre,

> -----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!
	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.

	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.


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

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

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

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

> Also in your references list, you list RFC 2131 as Authentication for DHCP
> Messages.  That's RFC 3118. 
	[MR>]  Thanks for hinting that mistake. It will be corrected.

> Also, you make no actual reference to DHCP Authentication within your
> draft.
	[MR>]  I haven't yet thougt much about that.  

> BTW: Does this draft have implications for the zeroconf people? 
	[MR>]  I think It might go somehow into their direction.

	Best Regards,
	             Markus


	 
> > -----Original Message----- 
> > From: Rentschler, Markus [ <mailto:[e-mail]>] 
> > Sent: Monday, November 03, 2003 2:42 AM 
> > To: [e-mail] 
> > Subject: [dhcwg] ID's: DHCP Discovery Extensions / Interface 
> > Information 
> > Option 
> > 
> > 
> > Hello DHC-WG, 
> > 
> > I seem to have missed the deadline for ID submission, but need some 
> > criticism/feedback on the issues described in the enclosed 
> > drafts. Please 
> > read through the documents and let me know your comments. 
> > 
> > The abstracts of these drafts are given here: 
> > 
> > -- DHCP Discovery Extensions -- 
> > 
> >    This draft defines simple protocol enhancements to DHCP so that it 
> >    can be used for the following applications: 
> > 
> >    - Discovery of clients in the network 
> >    - DHCP server redundancy 
> >    - Server-initiated configuration of clients 
> > 
> >    The discovery mechanism described here is built upon and coexists 
> >    with BOOTP according to RFC 1542 and DHCP according to RFC 2131 
> >    and RFC 3203. 
> >    It allows server-initiated communication to specific or 
> > all clients 
> >    in the network, using the DHCP packet format. Other DHCP servers 
> >    in the network can be provided with information about all 
> >    existing client configurations and will therefore be able to take 
> >    over if the main server fails. 
> > 
> >  <<draft-rentschler-dhc-discovery-00.txt>> 
> > 
> > 
> > 
> > -- DHCP Interface Information Option -- 
> > 
> >    This draft defines a new option to inform the server about 
> >    the client's physical interface it is connected to. 
> >    This information may be used together with the relay agent 
> >    information option (RFC 3046) for the purpose of topology 
> >    recognition. 
> > 
> >  <<draft-rentschler-dhc-interface-opt-00.txt>> 
> > 
> > 
> > 
> > Best Regards, 
> >            Markus Rentschler 
> > 
> > 
> > 
> 

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