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

From: "Kostur, Andre" <[email-masked]>
Date: Tue, 4 Nov 2003 09:14:17 -0800

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

Assuming that a client SHOULD always send the IIO to the server, what does
it fill it with in the original Discover?  At this point it has never
recieved a Server->Client packet.

What benefit does this particular option give over simply using the existing
Client Identifier (Opt 61) to encode such information? (Which still doesn't
address what happens on the original Discover)

You note in section 1:

   The relay agent information option [RFC 3046], which is added by
   a relay agent to a client's request to the server, contains in its
   Circuit ID sub option the number of the physical interface on which
   the relay received this client's request..

Keep in mind that devices using opt 82 aren't required to have a circuit ID.
The wording of the above should reflect that a device MAY add a circuit ID.
As well, the service cannot assume what the contents of a Circuit ID
represents.

---

From: "Rentschler, Markus" <[email-masked]>
Date: Thu, 6 Nov 2003 14:20:49 +0100

> ...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.
	[MR>] 
	That's correct. The same will be the case with the IIO.
	The server is free to use it or not, that depends entirely on the
server implementation.

> 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.
	[MR>]  
	This is also true. But I see it as a potential limitation, not as a
necessary restriction.
	It reduces flexibility of the protocol (just my humble opinion).

> --Barr
	-----Ursprüngliche Nachricht-----
	Von:	Barr Hibbs [SMTP:[email-masked]]
	Gesendet am:	Donnerstag, 6. November 2003 00:55
	An:	Rentschler, Markus; Kostur, Andre; [email-masked]
	Betreff:	RE: [dhcwg] ID's: Interface Information Option

	Best Regards,
	                 Markus

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

---

From: Markus Rentschler <[email-masked]>
Date: Fri, 7 Nov 2003 10:32:37 +0100

[MR] comments inline....

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Rentschler, Markus
> Sent: Thursday, November 06, 2003 00:11
> >
> > What benefit does this particular option give over simply using the
> > existing Client Identifier (Opt 61) to encode such information?
> > [MR>]  There are several benefits:
> >
> > -- Another parameter for more tightly IP address allocation schemes for
> > higher security. (The server configurator can for example say: a certain
> > IP address/configuration is only allowed to a certain client
> > (use MAC and /or Client-Id) on a certain location in the network
topology
> > (use Option 82) that is connected via a certain interface (use IIO).
> > Any other useful combinations with other client's parameter as trigger
> > conditions may be thought of...
> > -- Possibility for topology discovery and therefore detection of
> > misconfigured connections.
> >
...you've obviously never had to manage an extremely large, widely dispersed
client population with a diverse technician workforce.  It is AN EXTREMELY
BAD IDEA to try to "lock-down" devices by insisting on strict, unchanging
relationships between MAC addresses, Client Identifiers, Host Names, hub,
switch, or router ports, and other network elements.

[MR]
That might all be right in environments you are used to (office world ?).
In some other areas there are completely different requirements!
Dynamic adressing for example is hardly ever used in our field.
Redundancy, security, tight control of everything in the network has a very high priority.
Such networkers might be a minority, but does that really matter in this case?

The principal benefit of DHCP is to reduce the need for detailed
recordkeeping and configuration which represents a huge savings in labor
costs, and reduced troubleshooting and repair times.
Don't arbitrarily throw out that major benefit in the pursuit of the elusive
goal of "improved security" -- 

[MR]
Nothing is thrown out by adding a new option... 

when was the last time your organization, or
ANY organization of which you had knowledge, was penetrated by someone
plugging in an unauthorized network device?

[MR]
Even the possibility can make some people sleepless... 

Question: Why it is a goal of the dhcp wg to improve security, authentication 
and all that stuff  if security doesn't really matter that much to you ;-)

Best Regards,
            Markus