Subject: WG consensus action - 1 week to discuss [LL2] Explicit Additional Mechanism to disable v4 LL

From: Erik Guttman <[email-masked]>
Date: Mon, 17 Feb 2003 17:59:40 +0100

Please discuss this issue in the next week.  Our goal is to achieve
WG consensus.  Please try to stay on-topic during the discussion.

See also http://www.spybeam.org/ll2.html

We should strive to conclude this discussion by Feb 24.

===================================================================

Description of Issue  Explicit Additional Mechanism to disable v4LL 
Submitter Name  Erik Guttman
Submitter Email Address  [email-masked]
Date first submitted  6 Feb 2002
Reference  http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00459.html
Security considerations with the proposal:
http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00473.html 
Comment Type ['T'echnical | 'E'ditorial] T
Priority ['S' Must fix | '1' Should fix | '2' May fix ] S
Section Not in document presently.
Rationale/Explanation of issue:
The specification should be modified to define or require some 
additional mechanism to disable IPv4 LL autoconfiguration. This 
mechanism would be mandatory to implement and cause all hosts using IPv4 
LL to stop doing so.

Lengthy description of problem:

... the desire to have a way to disable LL addresses
isn't so that the network manager can make sure that no-one can use
the net without their permission, or similar, that's ludicrous, the
node(s) could just configure themselves with network 10 addresses,
or 192.168, or anything else (including addresses from the block that
are designated for use on the net in question).

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. What is 
requested is RFC 2563 or some derivative. Requested Change: 1.3 
Alternate Configuration Mechanisms

As explained in the previous section (1.2), the link-local addresses
assigned by this protocol are intended for small ad-hoc networks.
However, it is very rare for a system to be constructed that can
only ever be connected to such networks. When connected to a
properly managed network, nodes should operate correctly for that
network.

To allow for this, all nodes that implement this protocol MUST also
provide some mechanism to allow for routable addresses to be configured.
That mechanism MAY use the DHCP protocol [RFC2131] in appropriate cases,
but other means, such as manual configuration, are also adequate.

Many nodes using this protocol, on large networks, can cause excessive
traffic as explained in the previous section (1.2). For this reason,
and others, it can be necessary to disable use of link-local addresses
in some situations where they are not required. The configuration
mechanism provided MUST provide a mechanism to disable the assignment
of link local addresses on an interface. Where that configuration
mechanism uses DHCP, the node MUST implement the DHCP option to disable
stateless auto-configuration in IPv4 clients [RFC2563].

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 21 Feb 2003 11:00:34 -0000

I reject LL2

I note that once again we have a text that combines two separate issues:

> ...all nodes that implement this protocol MUST also
> provide some mechanism to allow for routable addresses to be configured...

and

> ...Where that configuration

I disagree with the second of these because it adds complexity for dubious
gain, and therefore I cannot support LL2.

I am currently undecided on the first issue which is roughly the same as
LL27

Philip

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Feb 2003 09:35:28 -0700

> gain, and therefore I cannot support LL2.

I also reject LL2, for the same reasons you've stated.

I think perhaps we should add a new issue that proposes a change 

I'm suggesting that it should be this instead:

>> ...nodes that implement this protocol SHOULD also