Subject: [LL14] [LL15] [LL30] Multi-interface hosts

From: Robert Elz <[email-masked]>
Date: Sat, 05 Apr 2003 19:40:27 +0700

Ignoring [LL30] for now, that is, assuming it gets rejected (see below),
what's the downside of simply requiring hosts to assign different
LL addresses to each interface ?

That is, what conceivable benefit is there in having the same
LL address on more than one interface?

If there's none, and at the minute I certainly can't think of one,
then we may as well simply require that hosts don't allocate the
same address on any two of their interfaces.

It isn't as though there aren't plenty of LL addresses to go
around (I can't really imagine a host with 64K interfaces, and
desiring to allocate LL addresses on all of them - that is, hosts
with large numbers of interfaces usually have most of them being
point to point interfaces (serial, or more likely, tunnels) and
allocating LL addresses on those seems totally pointless (mostly,
I suppose someone will dream up a use in some odd circumstance).

If we were to require that a host use distinct LL addresses on all
interfaces, then both LL14 becomes moot I think.

The proposed resolution of LL15 also becomes the obvious thing to do.

However, I'm not sure what that resolution has to do with the problem
in Ll15.   I also have no idea why the wording that LL15 is objecting
to is there in the first place.

That is, why would a host care that one of its addresses is owned by
another host on some other link.   I guess that the hope is that it
would allow a host to talk to any other host, without ever being fooled
into thinking it is talking to itself, and without having to keep some
kind of "scope identifier" around to distinguish the cases "me talking
to 169.254.22.33 on link A" and "me owning 169.254.22.33 on link B".

But that's bogus anyway, it can't be done, the node still needs
to know on which link a LL address is located, or the requirement
would have to be altered to insist that a multi-interface node should
repeat address probes out all other interfaces, and then respond on the
original interface if anyone were to respond to a repeated probe (and
at the same time, create some kind of mechanism for loop avoidance).
That is, somehow the node would need to assure itself that the same
address can't be in use by two different nodes on any two links to which
it is connected.

That's impractical (especially using just ARP to accomplish address
assignment).  This means that nodes MUST keep track of on which link
every link local address resides, and treat that information as a part
of the address (for identification purposes anyway).   This is exactly
as IPv6 has done.   As soon as you admit that, there is no longer any
rationale for wanting to avoid some other node on link B using the same
address as I'm using on link A, as the addresses are all qualified by
some kind of identification of each link.

Of course, the alternative to all of this would be LL30, but "NOT
RECOMMENDED" wouldn't be strong enough, "NOT DEFINED" would really
be needed (that is, for anyone who attempts that, making it work is
their problem, the WG spec has nothing to offer to help).

I could almost support that if I could think of any way to decide
which particular interface should be the blessed one to get LL
addresses, and accomplish that without configuration.   But I'm afraid
I can't do that, no one interface (link) is necessarily better suited
than any other to having LL addresses assigned to it.

Without some way to pick a blessed interface (the "first found" by
the hardware probe doesn't sound attractive to me, nor "first in some
sort order or interface names" or something) I don't think that LL30
is sustainable.

That means that we do have to deal with multi-interface hosts.   Which
means that we should, I suggest, demand different addresses on each
interface, ignore LL14, and certainly do what LL15 suggests, which I
think causes the "bad bits" in the current doc to go away.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: 05 Apr 2003 16:26:38 +0300

Hi Robert,

I agree completely. Let's reject LL30 and require that each interface
assigns its LL address independently. All this removes a lot of crud
from the draft.

	MikaL