Subject: Re: [Issue 2] Explicit Additional Mechanism to disable v4LL

From: Bernard Aboba <[email-masked]>
Date: Sun, 9 Feb 2003 17:40:54 -0800 (PST)

I agree that this issue should be rejected.

If we go the route of preferring routable addresses to V4LL ones if both
are available, then the way to control use of v4LL is to make sure that
hosts get a routable address -- in other words, keep your DHCPv4 server
running.

---

From: "John C. Welch" <[email-masked]>
Date: Sun, 09 Feb 2003 22:20:58 -0500

> hosts get a routable address -- in other words, keep your DHCPv4 server

If you are in a high security environment, the implicit disabling of v4LL
due to the presence of a DHCP address is not enough.

If you are trying to set up an ad hoc network in range of an open DHCP
server, you'll never be able to.

If you have a manual address configured, and you need to print at a new
location to a v4LL printer, you won't be able to.

If your DHCP server goes down, and you can't get another one up, because
you're on a home network, your DHCP server is your little cable router and
you don't know how to reset your DHCP leases, (because you're using a Mac,
and OS X doesn't give you an easy way to do this), you can't even talk to
the computers in your house until the lease expires.

There are a host of reasons for having a human override to automatic
configurations, they exist *now*...manual config can overrride DHCP config.
I'm saying, let's make v4LL's easy and flexible.

john

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

---

From: Robert Elz <[email-masked]>
Date: Mon, 10 Feb 2003 16:16:35 +0700

Date:        Sun, 9 Feb 2003 17:40:54 -0800 (PST)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | If we go the route of preferring routable addresses to V4LL ones if both
  | are available,

That's very likely I think.

  | then the way to control use of v4LL is to make sure that
  | hosts get a routable address -- in other words, keep your DHCPv4 server
  | running.

That assumes that the DHCP server wants the node in question connected
(at all) to the network it is attached to, doesn't it?   What do you do
when the DHCP server wants to say "you are on the wrong network" ?

kre

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Feb 2003 04:55:27 -0800 (PST)

> when the DHCP server wants to say "you are on the wrong network" ?

Normally, the DHCP server sends a NAK in that circumstance, no?

---

From: Robert Elz <[email-masked]>
Date: Mon, 10 Feb 2003 22:02:17 +0700

Date:        Mon, 10 Feb 2003 04:55:27 -0800 (PST)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | Normally, the DHCP server sends a NAK in that circumstance, no?

no.

kre

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Feb 2003 09:54:12 -0600

> Normally, the DHCP server sends a NAK in that circumstance, no?

No, it sends no response to the DHCP client.   A DHCPNAK can't be sent 
in response to a DHCPDISCOVER.

---

From: Mika Liljeberg <[email-masked]>
Date: 10 Feb 2003 22:52:06 +0200

> hosts get a routable address -- in other words, keep your DHCPv4 server

I agree with this statement and with the proposal that LL2 should be
rejected.

A manual configuration option to disable v4LL should suffice for high
security environments.

	MikaL

---

From: "John C. Welch" <[email-masked]>
Date: Mon, 10 Feb 2003 18:48:27 -0500

> A manual configuration option to disable v4LL should suffice for high

That's what LL2 is asking for...a manual mechanism to disable v4LL

john

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

---

From: Mika Liljeberg <[email-masked]>
Date: 11 Feb 2003 09:31:14 +0200

> That's what LL2 is asking for...a manual mechanism to disable v4LL

It's asking for RFC2653 or some derivative.

I'd be willing to agree to manual configuration locally on the node, but
not with the current LL2 proposal.

	MikaL

---

From: Robert Elz <[email-masked]>
Date: Tue, 11 Feb 2003 16:05:10 +0700

Date:        11 Feb 2003 09:31:14 +0200
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1044948673.1377.22.camel@devil>

  | I'd be willing to agree to manual configuration locally on the node, but
  | not with the current LL2 proposal.

This only works if you're also willing to mandate some kind of stable
storage in every node supporting v4LL addresses.   I don't think that's
reasonable.

kre

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Feb 2003 08:48:29 -0500

> storage in every node supporting v4LL addresses.   I don't think that's

nor do I.  which is why I've tended to say that such a feature is highly
desirable, maybe even a SHOULD, but not a MUST.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Feb 2003 10:12:22 -0600

> storage in every node supporting v4LL addresses.   I don't think that's

Can you give us an example of a device that you can buy today that 
autoconfigures on the network but does not have any nvram?   If not, 
your definition of "not reasonable" is pretty extreme.   The only thing 
I can think of is a mote, and I'm not even sure *those* are devoid of 
nvram.

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Feb 2003 22:31:40 +0700

Date:        Tue, 11 Feb 2003 10:12:22 -0600
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

Now this issue is open for discussion, I will reply to this old(ish) message...

  | > This only works if you're also willing to mandate some kind of stable
  | > storage in every node supporting v4LL addresses.   I don't think that's
  | > reasonable.
  | 
  | Can you give us an example of a device that you can buy today that 
  | autoconfigures on the network but does not have any nvram?

not off hand.   Though NetBSD-live (i386live) (the NetBSD that boots and
runs entirely from a CD) is probably close (a PC with no writable discs
has no stable storage that is useful for its OS - the BIOS config space
isn't really available or useful).

  | If not, 
  | your definition of "not reasonable" is pretty extreme.   The only thing 
  | I can think of is a mote, and I'm not even sure *those* are devoid of 
  | nvram.

What really matters for this though is whether you are willing to have
the standard say:

	Link local addresses MUST NOT be implemented on devices without
	stable storage for configuration information.

And whether you think you can get the rest of the WG to agree with you.

I don't think that's needed, I certainly don't think it is possible.
But without it, I do think we need a dynamic way to disable use of LL.

I actually think we need a dynamic enable/disable mechanism anyway, as
stable storage doesn't tend to be updated easily when a node moves from
one LAN to another, but what addresses (or address types) should be used
there certainly does.

kre

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Feb 2003 11:50:10 -0700

> isn't really available or useful).

The NetBSD live CD is itself stable storage - it has to have some kind 
of configuration burned onto it in order to be useful.   If you don't 
want your NetBSD live system to do IPv4ll, all you have to do is burn a 
CD that is configured not to do IPv4ll.   So this is a bad example.

> And whether you think you can get the rest of the WG to agree with you.

No, I'm not willing to have the standard say that.   I am willing to 
have the standard say something like "Devices that implement link-local 
addressing SHOULD have a mechanism whereby they can be configured not 
to attempt IPv4ll addressing."

I've seen long diatribes by various people with amazingly strong 
opinions as to why IPv4ll absolutely MUST be disableable, but I've 
never heard anything that convinces me that we need any stronger 
language than what I've stated above.   My point in asking you to come 
up with an example of a device without stable storage was to illustrate 
why I do not think stronger language than this is needed, not to assert 
that it is completely inconceivable that such a device could ever exist.

MUST makes sense in situations where if you don't follow the spec, you 
don't have interoperability.   If you say MUST, and the implementor 
doesn't follow the MUST, his or her application should fail to 
interoperate in the circumstances addressed by the MUST.   So it is 
simply not appropriate to say MUST here - there is no interoperability 
issue.   For operational issues, we say "SHOULD" if we strongly feel 
that every implementation should follow the recommendation, or "MAY" if 
the recommendation is optional.