Subject: [Issue 23]: Don't configure needless LLv4 addresses

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Feb 2003 08:28:05 -0800 (PST)

I am in favor of this change, although I think that if it is accepted, we
don't also need the change proposed in Issue #1.

Issue 1 deals with when LLv4 addresses are used. This issue attempts to
restrict when they are configured. To some extent the text of the two
issues overlap. Overall, I think I like the text of 23 better than Issue
1, because it deals with the issue of initiating new connections vs.
continuing to use old ones, and is more specific.

Comments on the text:

"Having addresses of multiple different scopes assigned to an interface
with no adequate way to determine in what circumstances each address
should be used leads to complexity for applications and confusion for
users. A node with any address assigned for a link can communicate with
all other devices on that link, whether those other devices use link-local
addresses, or routable addresses."

Yes, this is true now that we have accepted Issue #17.

"For this reason, a host that obtains, or is configured with, a routable
address on an interface, SHOULD NOT attempt to configure a
link-local address on the same interface."

I am not entirely sure what configure means here. Does it mean the same
thing as SHOULD NOT use? How is it different? What specific things does
this imply aren't done? Are they all covered in the next paragraph?

"Where a link-local address has been configured on an interface, and a
routable address is later configured on the same interface, the host
MUST always use the routable address when initiating new communications,
and MUST cease advertising the availability of the link-local address
through whatever mechanisms that address had been made known to others."

This makes sense, I think. I assume that "advertising" doesn't include
ARP replies.

"A host SHOULD continue to use the link-local address for communications
underway when the routable address was configured, and MAY continue to
accept new communications addressed to the link-local address."

This is good. Assuming we accept these changes, why do we also need the
resolution to Issue #1?

---

From: Mika Liljeberg <[email-masked]>
Date: 17 Feb 2003 20:49:33 +0200

I'm reserving judgement on LL1 and LL23 for now.

> this imply aren't done? Are they all covered in the next paragraph?

The text also fails to deal with the issue what to do if the routable
address is unconfigured (e.g. by a frustrated DHCP client).

> This makes sense, I think. I assume that "advertising" doesn't include

What exactly does advertising include? What is the implication to an
implementor? Unless these questions can be answered, the sentence should
be deleted.

> accept new communications addressed to the link-local address."

I like this bit.

> This is good. Assuming we accept these changes, why do we also need the

We don't. I believe LL1 and LL23 are alternative proposed solutions to
the same issue. We can accept either one or we can reject the issue.

	MikaL

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Feb 2003 09:51:40 -0800 (PST)

> address is unconfigured (e.g. by a frustrated DHCP client).

If the DHCP client doesn't obtain an address, then the routable address
would not be configured, no? So I think that part is covered.

> implementor? Unless these questions can be answered, the sentence should

Since there are presumably going to be a bunch of prohibitions on
"advertisement" of link local addresses (e.g. don't register them in DNS,
don't hand them out in applications, etc.) my guess is that this applies
to the remaining mechanisms that are allowable (such as answering LLMNR
queries). But you are right that we need to be specific here.

> the same issue. We can accept either one or we can reject the issue.

Right. I guess I'm for rejecting LL1 and accepting LL23 with
modifications.

---

From: Mika Liljeberg <[email-masked]>
Date: 17 Feb 2003 21:15:23 +0200

> would not be configured, no? So I think that part is covered.

I was thinking lease expiry or manual unconfigure. What will happen if
the routable address disappears? Will the node be left without an
address or will it acquire a v4LL?

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Feb 2003 14:25:15 -0500

[subject line changed to make tracking easier]

> > implementor? Unless these questions can be answered, the sentence
> > should be deleted.
> 
> "advertisement" of link local addresses (e.g. don't register them in
> DNS, don't hand them out in applications, etc.) my guess is that this
> applies to the remaining mechanisms that are allowable (such as
> answering LLMNR queries). But you are right that we need to be
> specific here.

actually you don't want to be too specific, because the problem occurs
anytime the address is advertised as being associated with a service,
via any means - be it DNS, DHCP, SLP, LLMNR, or something that is
application-specific.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Feb 2003 10:15:56 -0800 (PST)

> via any means - be it DNS, DHCP, SLP, LLMNR, or something that is

Well, that's still more specific than the text we have now :)

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Feb 2003 19:03:13 +0700

Date:        Mon, 17 Feb 2003 08:28:05 -0800 (PST)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | I am in favor of this change, although I think that if it is accepted, we
  | don't also need the change proposed in Issue #1.

LL23 was intended as an alternative to LL1.   This was submitted during
the period (which may still exist, though mostly seems to be being
ignored) when the requested way to suggest an alternative resolution
for an issue was to submit a new issue.

  | "For this reason, a host that obtains, or is configured with, a routable
  | address on an interface, SHOULD NOT attempt to configure a
  | link-local address on the same interface."
  | 
  | I am not entirely sure what configure means here.

Run the LL assignment algorithm (actually assign an LL address to an 
interface).

By all means suggest wording improvements.

  | Does it mean the same thing as SHOULD NOT use?

No, except that if an address isn't configured, it would be rather
difficult to use it...

  | How is it different?

"use" is ambiguous, it could refer to assigning an address to an interface,
or sending (or receiving) packets with an address in it.   "Configure"
is intended to refer to only the first.

  | What specific things does this imply aren't done?
  | Are they all covered in the next paragraph?

Largely, I hope so.

  | This makes sense, I think. I assume that "advertising" doesn't include
  | ARP replies.

no, that's a reply - an advertisment is something unsolicited (some way
of causing others to issue an ARP request, that is of allowing them to
discover what IP address to use in the first place).   Or that is what was
intended.   The idea is that the system attempt to cause people to use
the routable address, instead of the LL, wherever possible - but I don't
think we need to much specific language as to how that can or should be done,
it depends upon too many other issues that aren't otherwise relevant here
(this draft doesn't, itself, give anyone a clue as to how they'd discover
someone else's LL address - nor does it need to).

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Feb 2003 19:09:17 +0700

Date:        17 Feb 2003 20:49:33 +0200
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1045507773.17019.62.camel@devil>

  | The text also fails to deal with the issue what to do if the routable
  | address is unconfigured (e.g. by a frustrated DHCP client).

By all means, suggest wording to fix that.   That's a reasonable point.

I'd expect that if the host has a LL address from earlier, it would go
back to using it as it would if the routable address had never existed,
and if it doesn't, it would go and acquire one.

That is, assuming that LL2 hasn't told it not to configure a LL address
of course.

  | What exactly does advertising include? What is the implication to an
  | implementor? Unless these questions can be answered, the sentence should
  | be deleted.

I'd prefer to keep the sentence, and not answer the questions.   Answering
the questions means embedding more knowledge in this draft that isn't
needed, about the methods by which link local addresses of other nodes
are determined.

It would be reasonable to add (in the definitions of terms section)
something along the lines of

	advertising	any process by which a node makes known to
			others its randomly selected link local address.

(note that this does not include information made known by third parties,
but does include the node notifying the third party in the first place).

kre