Subject: RE: Link Local Address usage for multi-home host.

From: "sasson, shuki" <[email-masked]>
Date: Tue, 22 Oct 2002 08:47:54 -0400

Hi Robert & Keith, this is an interesting discussion. The fact that the
scope field is not a part of the address in cases like Link Local is the
problem.
From my perspective as an application implementer it is the problem. Current
applications works with addresses assuming (and this is very natural) that
there can be only one entity with this number (Also a very long number 16
bytes!). 
What happens is that for these special case (Link Local mainly) the
application will have to look at the scope field in the socket to find out
which zone it is. You pointed right that the zone number is actually a part
of the address. May I add: which doesn't exist on the address.
There are some amusing implications on implementers for instance BSD stores
the IfIndex on the address itself (the second byte of the address).
A direct result of this zoning is also that the application now has to
distinguish between the addresses Link Local look at the scope Global don't
look at the scope.
Isn't porting a current application to support 16 bytes is hard enough?
By the way, the neighbor discovery RFC clearly states that the fact that
multi-homed hosts will not function well is known to them and they ask us
the developers to experiment with it and give them feedback.
Here is the feedback:
Link Local addresses should be globally unique addresses so scoping
shouldn't be a problem (64 bits should do...).
We are still debating what to do with this... We thought we have a simple
scheme for a solution for this, apparently we have to work a little bit
more.
Any suggestion for simplifying our lives will be welcomed.

Shuki  

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

    Date:        Mon, 21 Oct 2002 17:03:58 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | because if you want apps to work reliably under these 
  | conditions then you are essentially asking hosts to do routing in
  | the absence of routing information

Sorry Keith, but what has routing got to do with anything?   Address
scoping is really just yet another level of naming, it is an extension
to the address.

Given any random address, with or without scoping information, there's
always a possibility that the address won't work, for all kinds of
reasons, so apps better be prepared to deal with that one way or another.

That is, if you consider it important for an app to know which of several
possible addresses (perhaps all "global" address) will work before using
one, then you're right, there's a whole bunch of extra info that hosts would
need to somehow discover first, but in practice, that isn't what anything
does, "suck it and see" is the traditional approach - given multiple
addresses,
pick one (at random, though first come tends to be better) and see if it
works, if so, then fine, if not, go on to the next.

There's nothing about scoping that changes that in the slightest.   Of
course, the appropriate scope info has to be available with each address.
The DNS has no way to return that info (nor do we have any global naming
scheme for scopes that would allow it to), which is one reason why limited
scope addresses should never appear in the DNS, except where the limited
scope is (for other reasons) defined to be the universe (which is how we
get by putting our current global addresses in the DNS - the globe of
concern is "our globe" and all global addresses by definition refer to it).

Other means of locating suitable limited scope addresses need to provide
the scope information as a by product (which in many cases can be done by
simply using the appropriate scope identifier from the interface over
which the address was discovered).

I know you're concerned about apps (protocols) which pass around addresses
in the data (and consequently which aren't limited by the normal scope
control measures).  Where that happens the apps just need to take care not
to pass an address to a node where it isn't known to be meaningful.
Since that's hard to determine, a simpler rule that works, is simply never
to pass an address of a lesser scope (more restricted scope) than the
address being used for the peer in the communications over which the
address is to be sent.

Certainly that's something that apps aren't doing now - but they should be.
It certainly isn't anything like as burdensome as the picture you have
been painting of the difficulties involved.

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]
--------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Tue, 22 Oct 2002 13:44:35 -0400

> shouldn't be a problem (64 bits should do...).

that would help.  it would also help if we made it very clear that
LL addresses were really only for bootstrapping and local network
functions, NOT for applications.  similarly for site locals.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Wed, 23 Oct 2002 18:22:36 +0700

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