Subject: LL2 comment

From: "John C. Welch" <[email-masked]>
Date: Sat, 08 Feb 2003 14:32:30 -0500

If this is the incorrect way to respond, I apologize.

In addition to this reason:

" The reason is because the net manager knows what will, and won't work
properly on their net, and can provide advice to the nodes as to what they
should do in order to work well in the local environment."

There are also environments where the configuration has to be explicitly set
/ limited. Even where DHCP is used, and would implicitly disable v4LL, that
is not enough of a guarantee that v4LL is turned off.

I would propose that the default configuration MUST be that v4LL is enabled,
and that the first use of this 'switch' would be to turn it off. This way,
you have zeroconf by default, yet can ensure it is off, regardless of global
address config mechanism. (if you have that need.)

Recommendations for the mechanism would include a switch to ifconfig, if
appropriate, or a checkbox on a web config page, an option on a cl config
screen, etc.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Keith Moore <[email-masked]>
Date: Sat, 8 Feb 2003 16:55:27 -0500

> address config mechanism. (if you have that need.)

absolutely, totally unacceptable, and without a shred of justification.

Keith

---

From: Thomas Narten <[email-masked]>
Date: Mon, 10 Feb 2003 07:34:49 -0500

> is not enough of a guarantee that v4LL is turned off.

The above seems to say that if DHCP is used, it would implicitely
disable v4LL. (I also assume, that the more precise statement here is
that i a node sends out DHC requests, and a DHC server responds and
assigns the device an address, that is the mechanism for disabling the
need to configure a LL address).

Why is this not enough to deal with the problem? Note: there is _no_
way to guarantee that v4ll is turned off. Implementations can be
broken. Implementations can chose to ignore the specs, etc. Thus,
we're not looking for a 100% solution. We're looking for one that
works good enough in practice.

But if there is a clear way to indicate "LL does not need to be used
on this network", why is this not sufficient?

Thomas

---

From: "John C. Welch" <[email-masked]>
Date: Mon, 10 Feb 2003 12:16:38 -0500

> on this network", why is this not sufficient?

Because if the DHCP server goes down, then v4LL would of course start up and
commence to trying  to get addresses.

There are environments where network access *has** to be explicitly
controlled. This already exists for DHCP...if you manually configure your
box, and there is no DHCP server, then you don't have DHCP. However, this is
not the case for v4LL. If you are in a DHCP environment, and DHCP goes down,
then you now have unauthorized networks creating themselves.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Mika Liljeberg <[email-masked]>
Date: 10 Feb 2003 20:59:58 +0200

> then you now have unauthorized networks creating themselves.

This is a bogus argument. User's can always manually configure
themselves an address and create unauthorized networks.

	MikaL

---

From: "John C. Welch" <[email-masked]>
Date: Mon, 10 Feb 2003 14:21:24 -0500

> themselves an address and create unauthorized networks.

No, they can't reconfigure machine settings if the permissions are locked
down correctly. For example, in Mac OS X, I can lock normal users out of the
network config utilities GUI and otherwise. Most other operating systems
allow this as well.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM