Subject: Proposed text for LL2

From: Robert Elz <[email-masked]>
Date: Sun, 09 Feb 2003 17:57:08 +0700

Here's some text that could be added to the document to deal with
issue LL2.

I'd suggest adding it as a new section 1.3 between what is now 1.2 and
1.3 (making 1.3 become 1.4, and so on, of course).

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: Mika Liljeberg <[email-masked]>
Date: 09 Feb 2003 15:14:43 +0200

> Here's some text that could be added to the document to deal with

LL2 isn't officially up for discussion yet, but since you started...

> but other means, such as manual configuration, are also adequate.

A very restricted device that is never intended to operate in a routed
network might not need anything besides v4LL. If this paragraph is
needed at all, I suggest rewording "nodes that are likely to be
connected into a managed network ...".

> stateless auto-configuration in IPv4 clients [RFC2563].

I guess I've already made clear what I think about mechanisms like this.
The problem with this is that it creates an unnecessary dependency
between DHCP and v4LL configuration.

If something like this is considered mandatory, it should be defined as
part of the v4LL mechanism itself rather than as part of every other
potential mechanism.

	MikaL

---

From: Erik Guttman <[email-masked]>
Date: Sun, 9 Feb 2003 14:34:20 +0100 (CET)

> connected into a managed network ...".

[WG chair hat off, WG participant hat on.]

The WG has members who assert there is a use case for a v4LL only
device.  This group will probably not accept any text which states that
configuration is required. 

The IESG on the other hand will likely reject a document which is seen
to promote v4LL-only devices as a recommended configuration.

The MUST above can be satisified by vendors in different ways (i.e. a
device can receive a protocol message which assigns parameters.  Common
example:  The device maintains a web server which allows posting of new
parameters.)  Please bear this in mind when responding to Robert.

> > stateless auto-configuration in IPv4 clients [RFC2563].

[WG chair hat on]

Robert, thanks for the text suggestion.  It helps to have a concrete
proposal to consider.  I will post it today.

I will wait to announce a 1 week discussion call until we have
alternative text.  This is the central issue we have to resolve. 

Erik

---

From: Robert Elz <[email-masked]>
Date: Sun, 09 Feb 2003 21:36:41 +0700

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

  | LL2 isn't officially up for discussion yet, but since you started...

No, If I was going to argue it, you would have seen a completely
different message.

All I was doing there was responding to Erik's request for proposed
text for LL2, LL4, LL5 and LL15.   (See the message with the Subject
"Issues clean up and text needed").

That was suggested text for LL2.

I'm not going to bother with LL4, LLl5 or LL15, those three I consider
to be typical IESG noise, and not worth spending any effort on.   On the
other hand, since they are typical IESG noise, if no-one spends any effort
on them, the IESG will probably just keep holding up the document forever...
(Note: this isn't saying that none of the points from the IESG are worth
effort, I am referring exclusively to those three).

I won't respond to the rest of your message until we actually are debating LL2.

Erik: it probably would be better if this one were left until after LL23
(or whatever it gets to be called when it is posted) is dealt with.

kre

---

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

I continue to be confused about the subtle arguments about disabling
LL.

Robert Elz <[email-masked]> writes:

> in some situations where they are not required.

What does this mean exactly? If those devices have normal addresses
assigned to them, they won't need to be using LL and the problem no
longer exists. Right?

Why on a managed network would there still be devices around that
insist on assigning LL addresses to their interfaces?

Thomas

---

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

Date:        Mon, 10 Feb 2003 07:45:32 -0500
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | Why on a managed network would there still be devices around that
  | insist on assigning LL addresses to their interfaces?

Thomas, if I bring my laptop to your office in IBM (wherever you are
located) and plug it in, I assume I'm likely to be on a managed network.
I also assume your managed network will never have heard of my laptop,
and depending on how it is run, might not want to allocate me a routable
address, right?

In that case, my laptop has 2 options.   Either it assigns itself a LL
address, or it does not.

Obviously I can cause it to do either of those (it is mind after all),
but assuming I am willing to accede to the wishes of IBM's network
managers (given I am connecting to their net, I should), don't you think
they should have some way to indicate which of the two options they'd
like my laptop to select?

kre

---

From: "Philip Nye" <[email-masked]>
Date: Mon, 10 Feb 2003 16:10:06 -0000

> From: "Thomas Narten" <[email-masked]>
>

Even in the case where hosts only get a LL address if they don't have a
global one there are reasons why a host may be running both addresses (I
know this isn't quite what you asked).

1. You had a LL address and have now got a global one but are still in the
process of transitioning to using the global one exclusively.

2. You have a configured address (either static or a valid lease on a DHCP
address) but it is not working so you assign a LL address too.

Philip

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Feb 2003 11:33:01 -0500

On Mon, 10 Feb 2003 16:10:06 -0000
"Philip Nye" <[email-masked]> wrote:

> Even in the case where hosts only get a LL address if they don't have
> a global one there are reasons why a host may be running both
> addresses (I know this isn't quite what you asked).
> 
> 1. You had a LL address and have now got a global one but are still in
> the process of transitioning to using the global one exclusively.
> 
> 2. You have a configured address (either static or a valid lease on a
> DHCP address) but it is not working so you assign a LL address too.

I agree that there are cases where a host can legitimately have both an
LL and a routable address.  I don't agree that your case #2 is a valid
one, because "address obtained from DHCP not working" is not a
justification for a host to configure an LL address.  How can a host
distinguish the case where an address is "not working" because the
address given to it was bogus, from several other legitimate cases?

---

From: "Philip Nye" <[email-masked]>
Date: Mon, 10 Feb 2003 16:41:23 -0000

> From: "Keith Moore" <[email-masked]>
>

I was rather vague on this - but consider the case where you unplug your
laptop at work and plug it in at home. It still has a valid DHCP lease but
that address and configuration are most unlikely to work.

This is a common use case which IPv4LL ought to address and I am not sure
how it does so. I made a suggestion in an earlier post "Detection of working
configured address".

Philip

---

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

> insist on assigning LL addresses to their interfaces?

Because a company will decide to do it to give their customers more
features, or customers will demand it, and wave checkbooks.

john

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Feb 2003 12:26:08 -0500

> device.  This group will probably not accept any text which states
> that configuration is required. 

There may be use cases for v4LL-only devices.  However there is no use
case for a v4LL-only device that merits IETF standardization.  Vendors
that want to produce v4LL-only devices that are only intended to work on
specific or highly-constrained networks are free to do so, but defining
behavior of devices on such networks is not in scope for IETF, and those
vendors should not be able to claim that such devices meet IETF
standards.

> to promote v4LL-only devices as a recommended configuration.

I hope they reject any document that permits v4LL-only devices to claim
conformance to the standard.  If they do not do so, I trust the IAB
will see fit to override the IESG on that.  Balkanazing IP is not
consistent with IETF's mission.

Any host that attempts to automatically configure an address MUST (or
at least SHOULD) initially, and at intervals thereafter, attempt to get
a routable address/netmask and a default route from DHCP and if such
are obtained, use these in preference to v4LL configuration.

So I'm strongly opposed to the text as suggested.  

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Feb 2003 12:46:01 -0500

On Mon, 10 Feb 2003 16:41:23 -0000
"Philip Nye" <[email-masked]> wrote:

> > > 2. You have a configured address (either static or a valid lease
> > > on a DHCP address) but it is not working so you assign a LL
> > > address too.
> >
> > I agree that there are cases where a host can legitimately have both
> > an LL and a routable address.  I don't agree that your case #2 is a
> > valid one, because "address obtained from DHCP not working" is not a
> I was rather vague on this - but consider the case where you unplug
> your laptop at work and plug it in at home. It still has a valid DHCP
> lease but that address and configuration are most unlikely to work.

media sense helps.

and a host really ought to be able to ask "is my lease still valid here"
without having to risk losing the lease if it's on the same network as
before.  however, I doubt we can fix those problems in this WG.

Keith

---

From: "Philip Nye" <[email-masked]>
Date: Mon, 10 Feb 2003 17:49:06 -0000

> before.  however, I doubt we can fix those problems in this WG.

This is part of transition from configured to unconfigured which is in the
charter.

However, I agree it is open ended.

Philip

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Feb 2003 15:43:44 -0500

> > media sense helps.
> >
> > and a host really ought to be able to ask "is my lease still valid
> > here" without having to risk losing the lease if it's on the same
> > network as before.  however, I doubt we can fix those problems in
> > this WG.
> 
> This is part of transition from configured to unconfigured which is in
> the charter.

I don't think it's in our charter to change DHCP, which is what is
needed.  And I don't think it's a good idea to make fixing this problem
critical path for the v4LL document.

and actually the issue is independent of v4LL, it exists even when none
of the hosts on a network use v4LL.

Keith

---

From: Robert Elz <[email-masked]>
Date: Tue, 11 Feb 2003 15:54:12 +0700

Date:        Mon, 10 Feb 2003 12:26:08 -0500
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | Any host that attempts to automatically configure an address MUST (or
  | at least SHOULD) initially, and at intervals thereafter, attempt to get
  | a routable address/netmask and a default route from DHCP and if such
  | are obtained, use these in preference to v4LL configuration.

Hmm - I agree with this (except I wouldn't require DHCP, just "a mechanism"
which we all know, for all practical purposes is going to be DHCP these days,
but RARP was used once, etc...)

  | So I'm strongly opposed to the text as suggested.  

Since I wrote the text that is the subject of this message, and since I
agree with you (mostly) what about the text do you strongly disagree with?

kre

(Of course, it would be easier if the web page were updated with the
suggested text...)

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 11 Feb 2003 10:20:28 -0000

> before...

Transition from configured to Zero-config is even harder than the other way.
But to meet the aims we should at least spell out a path. If that means
outlining reasonable changes which would be required of DHCP then this is no
bad thing even if they cannot be progressed here.

So what of my suggestion that you simply ARP your configured routes? on the
principle that if you cant reach a router than either you need new
configuration or LL is going to be as good as it gets.

We could build is a mechanism based on this - if you have configured routers
but can't reach them then you can establish LL - but it might require
periodic retries and all sorts of complexity.

Philip

---

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

> which we all know, for all practical purposes is going to be DHCP these
> days, but RARP was used once, etc...)

well, we need a uniform mechanism for all of these devices (else networks have
to guess as to which mechanisms are necessary), and DHCP is the most likely
candidate.  OTOH, RARP would almost be good enough.

---

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

On Tue, 11 Feb 2003 10:20:28 -0000

> bad thing even if they cannot be progressed here.

I'm reluctant to even suggest things because I don't know much about DHCP and
haven't really had the time to investigate it in detail.

But the first thing you need is for lease times to be much greater than the
time required to identify a failed DHCP server and fix it.  And if you need
short lease times due to a shortage of addresses, this translates to a
requirement that you be able to restore DHCP service very quickly.  This isn't
a protocol issue by itself - it's a configuration issue.

I take the time to identify and fix a DHCP server problem to be a few hours
for most managed networks.  It could be made smaller with appropriate
monitoring/alarms, hot backups for DHCP servers, and redundancy in the network
connecting DHCP servers to clients, which would allow for shorter lease times.
(note that the lease time could vary according to the availability of
maintenance personnel - e.g. leases could be longer on weekends.)  

The second condition you need to meet is that a DHCP server outage does not
immediately cause problems for hosts that already have addresses, even if they
try to renew during that time.  If a DHCP server might be inaccessible for
several hours, not only do lease times need to be greater than that, but hosts
need to renew their leases often enough that they will always have a lease
that lasts for longer than the server is likely to be down.

To give a concrete example, if the time required to fix a broken DHCP server
were 2 hours, leases might need to be say 6 hours, and hosts need to renew
their
leases every hour or so, getting a 6 hour extension each time.  Even if no
response were heard, the old lease would still be valid. That way every host
would have a lease valid for at least 5 more hours at the time that the DHCP
server went down.

To make this work, a host needs to be able to renew a lease without fear that
an existing lease will be invalidated.  DHCP should always renew a lease with
the same address if it is possible to do so. 

There are other requirements for robustness.  If there are multiple DHCP
servers on a network, they need to not conflict with one another.  Either they
need to provide consistent results, or hosts need to treat their leases as
separate from one another (each one hands out its own addresses, and hosts can
use multiple addresses at once).  DHCP servers need to be able to survive
power failures without losing lease assignments.  etc.

--

What does any of this have to do with LL?  Not much.  DHCP problems need to be
solved within DHCP.  The best way to avoid churn between LL and DHCP is to fix
DHCP to be more robust.  That way, a host will only use LL if it wakes up
while a DHCP server happens to be down, and only until the DHCP server comes
back up (plus the interval that the host waits before retrying DHCP).

---

From: Ralph Droms <[email-masked]>
Date: Tue, 11 Feb 2003 10:36:01 -0500

Keith,

I would be happy to follow up on your discussion of how to make DHCP more 
robust.  You've mostly got it right...there are some details I can fill in 
(I hope Ted and I have addressed most of them in "The DHCP Handbook").

But, I'm not sure this is the right venue and would suggest we should move 
a discussion about DHCP over to the dhcwg@ietf mailing list...

- Ralph

---

From: Mika Liljeberg <[email-masked]>
Date: 11 Feb 2003 21:53:04 +0200

> candidate.  OTOH, RARP would almost be good enough.

The main objection I have against a DHCP based mechanism is that it
creates a dependency between the DHCP client and the v4LL
implementation.

If a truly universal solution is required, it should be an integral part
of the v4LL specification. Your "magic ARP reply" idea might be
palatable, if it were specified in these terms.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Feb 2003 15:02:46 -0500

> > well, we need a uniform mechanism for all of these devices (else
> > networks have to guess as to which mechanisms are necessary), and
> > DHCP is the most likely candidate.  OTOH, RARP would almost be good
> > enough.
> 

I think we already have a dependency on DHCP, in practical terms.
The LLv4 spec just needs to reflect that.

It's not clear to me that the v4LL code needs to know about DHCP,
though it does need to be able to tell if there's a routable address
configured for an interface.  It doesn't matter how it got there.

> If a truly universal solution is required, it should be an integral
> part of the v4LL specification. Your "magic ARP reply" idea might be

I need to work on that some more.

Keith

---

From: Mika Liljeberg <[email-masked]>
Date: 11 Feb 2003 22:16:39 +0200

> > creates a dependency between the DHCP client and the v4LL

There doesn't need to be. There shouldn't be. That would be plain bad
design. I think this can be solved without introducing a dependency.

> configured for an interface.  It doesn't matter how it got there.

Using the presence of a routable address on the interface is not an
acceptable signal to turn off v4LL. A node should be allowed to have
both a v4LL and a routable address on the same interface, if that is how
it is configured. In this, several people actually agree with me.

> I need to work on that some more.

Great.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Feb 2003 17:16:21 -0500

> it is configured. In this, several people actually agree with me.

well, I probably do too, if it's explicitly configured.  I guess the point is
that the coupling between LL and DHCP need not be terribly complex.  But DHCP
was here first, and is widely deployed, and is much more generally applicable
than LL.  If LL needs to know about DHCP, so be it.  That's better than
forcing applications to know about network topology and scoped addresses, etc.

---

From: Robert Elz <[email-masked]>
Date: Thu, 13 Feb 2003 15:53:33 +0700

Date:        Tue, 11 Feb 2003 08:51:37 -0500
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | well, we need a uniform mechanism for all of these devices
  | (else networks have to guess as to which mechanisms are necessary),

No, I disagree with that.   It would certainly help to have a uniform
mechanism, as as much as vendors want to keep customers happy, I'd
expect that a uniform mechanism (likely to be DHCP) will be what happens.
But for the requirements here, there is no need for that - if I need to
have a DHCP server (also able to do BOOTP) a RARP server, a MOP server,
a ... server on my net, that is possible.

What is necessary is that there be some way to configure the devices, and
if that means that devices come with a CD and instructions "boot this on
your windows machine before connecting the device" then that suffices,
even if what then happens is some totally non-standard proprietary protocol.
I personally wouldn't buy any such thing, but that's not what counts.

kre

---

From: Erik Guttman <[email-masked]>
Date: Thu, 13 Feb 2003 10:11:47 +0100 (CET)

Folks,

Please try to focus on the items which are up for WG last call.

   The criteria for influencing the decision at the end of the last call
   is not number, length or vehemence of postings from a single
   contributor.  Rather, we will consider the technical merit of the 
   postings and the breadth of support. 

The goal is not to convince each other individually.  For example, there
is no requirement to get the submitter of an issue to agree they have
made a mistake.  Rather, we need to get our different views on the table
expressed clearly so we can make a determination. 

We must of course debate assertions which we do not agree with.  Debate
means: bringing up specific technical arguments, backed up with examples
and practical concerns that have not been brought up yet.

Thanks,

Erik
ZEROCONF WG cochair

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Feb 2003 08:47:26 -0500

> a ... server on my net, that is possible.

yes, it's possible for you to do that.  But I don't think it's acceptable to
require that in order to get random plug-and-ping devices to play well
on his network, an admin has to potentially implement a separate mechanism
for each device.   Requiring that the admin support 1 or 2 mechanisms (say DHCP
or RARP) is fine, more than that is too much.

> I personally wouldn't buy any such thing, but that's not what counts.

Manual configuration is acceptable as long as the device is required to be
configured manually before it will try to operate at all.  But if the device
tries to configure LL automatically, it needs to also check for DHCP
automatically.

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Feb 2003 08:48:50 -0500

oops sorry.  I had told one of the chairs I'd hold off on discussing LL2 
until it's back on the table, since we already have so many discussions going
on. I replied to the last message before I realized it was about LL2.

Keith