Subject: RE: Link Local Address usage for multi-home host. --- Still a pr oblem even using Zones.

From: "sasson, shuki" <[email-masked]>
Date: Fri, 25 Oct 2002 10:23:21 -0400

Hi all, I am following closely what is written here. Also I am thinking
about various solutions to the problem assuming LL uniqueness is not
guaranteed (someone told me it is guaranteed for Etherenet is that
correct?).
Lets say that as an implementers of a File Server we are implementing the
extra step of zones.
This means basically that we add a zone to each LL source address to
identify from which interface it was approaching...
Consider the following scenario:
Our multihome server is connected through a switch to multiple clients, all
on the same broadcast domain (link-local).
Lets say now that all the clients are using Link Local addresses. Both
Interfaces will view the same Link Local set of addresses but with different
zones (different interface...).
The routing table/applications will consider them as different entities!
I have no doubts that this will create all sorts of bugs in applications
that will treat those as two separate entities.

What this means is that now the multihome host will have to apply some zone
discovery methods (I don't know how, god help us...).

First Question
--------------
Any Ideas How The above can be resolved?

We are supplying our customers with ability to restrict access from some
clients and grant an access to others.
Lets say that in a Link Local environment the customer assigns global
addresses for all the clients and the server.
Since the it is a link Local environment the client contacts the server
using the LL address (Is that true?) and all these restrictions are
bypassed...

Second Question
----------------
Will a client will use the global assigned address to communicate in this
case or the LL?

Third Question
---------------
Lets say, we can't make any assumption about the address (meaning the client
may choose either global or LL). Let say we have 3 interfaces of the server
connected through a switch to all the clients. Will that mean that the poor
network manager will have to assign this restrictions 3 times for each LL +
zone on each interface? 

Comment
--------
What a mess...

Am I missing something?

Shuki
-----Original Message-----
From: Robert Elz [mailto:[email-masked]]
Sent: Wednesday, October 23, 2002 7:23 AM
To: sasson, shuki
Cc: Keith Moore; Brian Zill; [email-masked]
Subject: Re: Link Local Address usage for multi-home host. 

    Date:        Tue, 22 Oct 2002 08:47:54 -0400
    From:        "sasson, shuki" <[email-masked]>
    Message-ID:  <33CE6457C7003A478381BCD0B584DEC55EAE2C@srmoon>

  | Link Local addresses should be globally unique addresses so scoping
  | shouldn't be a problem (64 bits should do...).

It is all evry nice to desire this, but useless unless we have some
mechanism for actually making it happen.   And we don't.

Take SL addresses for a minute (where the issues this way are a little
easier - LL's need to be available to a node before it actually starts
communicating on the net, which makes them very hard to deal with).
SL's have a whole bunch of bits that was decided at Yokohama, and not
clallenged on the list, will be available to be considered as part of
the SL address - easily enough for everyone to have a a unique SL
address prefix (not routable, but unique).

But actually making that happen would require a whole identifier
assignment bureaucracy, and no-one wants to actually create (yet
another) entity like that.   So, instead, sites just invent their
own identifiers (perhaps in co-ordination with other sites that they
might some day want to exchange SL info with) and they're not expected
to be unique.

kre
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------