Subject: AW: [dhcwg] ID's: Interface Information Option

From: "Rentschler, Markus" <[email-masked]>
Date: Tue, 4 Nov 2003 08:48:47 +0100

Hello Andre,

	[MR>]  Im going to split my answers by subject...

	-----Ursprüngliche Nachricht-----
	Von:	Kostur, Andre [SMTP:[email-masked]]
	Gesendet am:	Dienstag, 4. November 2003 00:15
	An:	'Rentschler, Markus'; [email-masked]
	Betreff:	RE: [dhcwg] ID's: DHCP Discovery Extensions /
Interface Informati on Option

	Regarding: DHCP Interface Information Option 

	- According to RFC 2131, a DHCP Server MUST NOT supply a Parameter
Request List option to a client (in OFFER, ACK, or NAK), thus a server
cannot request this option.

	[MR>]  Ok. Then a client that has multiple interfaces SHOULD always
send the Interface Information Option to the server, without any request.
That wouldn't violate the restriction you've mentioned.

	Apart from that: I cannot see any useful reason for that
restriction, since it limits the potential of DHCP.
	Any idea what might be the background of that restriction ?

	Markus

> > -----Original Message----- 
> > From: Rentschler, Markus [ <mailto:[email-masked]>] 
> > Sent: Monday, November 03, 2003 2:42 AM 
> > To: [email-masked] 
> > 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Barr Hibbs" <[email-masked]>
Date: Wed, 5 Nov 2003 15:55:20 -0800

> 	Any idea what might be the background of that restriction ?
...there is NO requirement that a server do anything with options sent to it
that are not necessary for its primary purpose of configuring a client.  So,
for example, if a client sends the "Default WWW Server" option, the server
is free to ignore it, report it, or record it, all according to the
implementation and local administrative decision.

As far as the restriction on the Parameter Request List from server to
client, it's because the role of the server is to respond to requests from
the client (ignoring RFC 3202 for the moment as it has no known
implementations,) NOT the other way round.

--Barr