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

From: "Brian Zill" <[email-masked]>
Date: Thu, 17 Oct 2002 16:45:39 -0700

Yes, this can be an issue, but it's not really a serious problem.  Link-local addresses, like all scoped addresses, are disambiguated via their scope-id (which represents the zone they are valid in).  At the application layer, this is part of the sockaddr_in6.  So there is no ambiguity.  Applications which want to compare two addresses for equivalency simply need to include the scope-id when making the comparision.  It's very little work compared to porting an IPv4 app to be a protocol-independent app.

To answer your specific questions:
1) Yes, see above.
2) This should be a natural part of making the app protocol-independent.
3) There is no need to do this.  In fact, I'm aware of several apps which want to do the opposite (i.e. limit themselves to scoped addresses only, in order to deliberately restrict their reach).
4) As mentioned above, the sockaddr_in6 structure already contains the scope-id field, which serves the purpose you want (note that while the interface index is often the same as the scope-id for link-local addresses, it might not necessarily be so.  And for other scopes, the interface index isn't what you want anyway.  The scope-id will always disambiguate a scoped address on a given machine).

--Brian

> -----Original Message-----
> From: sasson, shuki [mailto:[email-masked]] 
> Sent: Thursday, October 17, 2002 13:34
> To: [email-masked]
> Subject: Link Local Address usage for multi-home host.
> 
> 
> 
> Hi all, 
> Link Local Addresses presents a new concept to the existing 
> IPv4 oriented systems. The concept is that two different 
> entities might have the same IPv6 (Link Local Address). The 
> big problem is that this goes up the stack up to the applications.
> 
> Example:
> NFS server, we would like to export it for a node that is on 
> the same link using a Link Local address. Up until now 
> mentioning the IP address was enough since it identified the 
> interface. With IPv6 one may have the situation where two 
> different interfaces may have the same Link Local address. In 
> this case the interface should also be mentioned by the user.
> 
> Another problem (using the NFS example):
> We may have a situation that two different entities (each of 
> them residing on a different link) will mount the file 
> system. Once again I think most of the application will not 
> work as expected in this case.
> 
> 
> My Concern:
> Presenting this ambiguity to the upper layer will require in 
> some cases redesign of the application. I do not think that 
> the developers of the IPv6 protocol were aiming for this... 
> From the little I have read Link Local addresses are used as 
> a mean to initially communicate with routers in order to 
> establish statefull Address Configuration (Global or Site 
> Local address..).
> 
> My Questions:
> 1. Has someone came across the same problem? What was the 
> solution chosen? 2. Should we redesign all the upper layer 
> application to properly support this? 3. Will restricting the 
> applications/clients to communicate only with global 
> addresses makes sense? 4. Will the new socket interface 
> include an interface index to properly resolve this ambiguity?
> 
> Thanks for your answers,
> Shuki Sasson
> Principal Engineer, Network Storage Group
> 	EMC²  		
> where information lives
> 
> Phone: 508 305 8515
> FaxNo: 508 435 8901
> Pager: 877 919 0794
> Email:  [email-masked]
> 
> 
> 
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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: Thu, 17 Oct 2002 20:49:27 -0400

> Yes, this can be an issue, but it's not really a serious problem.  

forcing apps to deal with scopes at all is a serious problem.
being able to compare scopes from different addresses only addresses
one small aspect of that problem.

though making an app 'protocol independent' is one example of having
apps deal with scopes since presumably the app may have to deal with
a mixture of v4 and v6 addresses, a mixture of v4-only and v6-only
and dual-stack hosts, and various kinds of connectivity (no v4, local
v4, global v4) X (no v6, local v6 only, global v6)

it should not be assumed that it's appropriate to expect every app to be
protocol independent.  there will be v4-only apps.  there will be v6-only
apps.  there will be apps that can run one or the other but not both.
this is a natural consequence of v6 deployment scenarios.

app vendors shouldn't expect that limiting themselves to scoped addresses 
provides anything in the way of security other than delusion.    it's not
appropriate for the vendor to assume that the site or local environment
is secure.

bottom line: there is insufficient justification for expecting apps
to deal with scoped addresses.

Keith

---

From: Robert Elz <[email-masked]>
Date: Mon, 21 Oct 2002 18:04:20 +0700

Date:        Thu, 17 Oct 2002 20:49:27 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | forcing apps to deal with scopes at all is a serious problem.

This is one view.   Another is that an address is just a number,
without some kind of scope to define its use, it is meaningless.
Even "global" needs something to say which globe is being considered.

It can be argued that all apps should always deal with address scoping
and always should have.

kre

---

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

> It can be argued that all apps should always deal with address scoping

yes, it *can* be argued.  OTOH, I haven't seen a convincing argument
for this.  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 - so ideally the hosts should
listen to routing updates and do their own route computation.
which sort of implies that they're attached to the network for
long periods of time rather than being nomadic.  and if you 
designed the network to work in this way then you'd want your 
higher-layer protocols to be able to tolerate multiple destination 
addresses and/or changes to the destination address (with all
of the security issues that this implies).

so no, the argument doesn't stand up to scrutiny.  at least, not
in anything resembling the current Internet.

Keith

---

From: Robert Elz <[email-masked]>
Date: Tue, 22 Oct 2002 15:17:13 +0700

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

---

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

> scoping is really just yet another level of naming, it is an extension

if an app has multiple addresses to choose from, and some work better
than others, and the ability of the app to function effectively 
involves choosing an address, the app essentially needs routing 
information in order to make that choice.

> reasons, so apps better be prepared to deal with that one way or another.

yes, this possibility always exists.  but we used to have a clean separation 
of function between the apps and the network - it was the network's job to 
get packets from source to destination, and the apps were not expected to 
know about network topology.   that way the app writer can concentrate on
how best to do the app's job, and the network could concentrate on routing
packets.  these days we are starting to expect the app (or more naively 
the host) to make decisions that require routing information, but without
giving them the routing information.  or in other words, we're saying
"some routing problems are hard, so we'll make them the problem of the
application writers and pretend that we've solved them".  right.

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

that was a fine strategy when a host had only a couple of addresses, and 
they were global, and all of the addresses worked most of the time.
it doesn't work well when hosts have several addresses of varying
scope, especially when combined with very ephemeral address-to-host 
bindings.  

> course, the appropriate scope info has to be available with each address.

and once you start trying to figure how to describe scopes you
find that what you really need is a global address space and routing
information.  

otherwise, what you're essentially saying is that having limited-scope
addresses causes no problems that aren't addressed as soon as we have
a solution to this other unsolved problem...

> to pass an address to a node where it isn't known to be meaningful.

there's no way for the app to know that.  

> address being used for the peer in the communications over which the

no, this isn't sufficient either because the app has no idea of the peer's
scope, much less the scope of the eventual users of those addresses.

and as long as we're telling people that it's okay to use limited scope 
addresses instead of global addresses, such apps are going to fail in
cases where they're expected to work. 

> Certainly that's something that apps aren't doing now - but they should be.

that's extremely naive.  there's no way for them to do this, but they
should be doing it anyway. in other words, we don't want to actually solve
the problems we're causing - we just want to pretend they're not problems
until they go away.

Keith

---

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

Date:        Tue, 22 Oct 2002 13:41:57 -0400
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | if an app has multiple addresses to choose from, and some work better
  | than others, and the ability of the app to function effectively 
  | involves choosing an address, the app essentially needs routing 
  | information in order to make that choice.

Not really, it needs something similar perhaps, but it isn't routing
information.  And in any case, this is true any time there are multiple
possible addresses, scoping of some addresses has nothing to do with it.

  | yes, this possibility always exists.  but we used to have a clean
  | separation of function between the apps and the network

We still do, nothing has really changed.

  | these days we are starting to expect the app (or more naively 
  | the host) to make decisions that require routing information, but without
  | giving them the routing information.

Once again, it is not routing.  Routing information isn't required.

  | that was a fine strategy when a host had only a couple of addresses, and 
  | they were global, and all of the addresses worked most of the time.
  | it doesn't work well when hosts have several addresses of varying
  | scope, especially when combined with very ephemeral address-to-host 
  | bindings.

Much of that is just the same for v6, except that hosts might have
lots more addresses, and v4 or v6, name to address bindings don't last
forever any more.

  | and once you start trying to figure how to describe scopes you
  | find that what you really need is a global address space and routing
  | information.

Global address space yes, routing information no.  And the former
assumes that we actually want to deal with limited scope addresses
at a global level, which we almost certainly don't.   Dealing with
them at a local level is sufficient.

  | otherwise, what you're essentially saying is that having limited-scope
  | addresses causes no problems that aren't addressed as soon as we have
  | a solution to this other unsolved problem...

no, we don't need to solve the hard problem to make them useful.

  | > 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.
  | 
  | there's no way for the app to know that.  

Which is ...

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

what I just said.

  | no, this isn't sufficient either because the app has no idea of the peer's
  | scope, much less the scope of the eventual users of those addresses.

No, you didn't read what I wrote, I suspect.   If A and B are communicating
using global addresses, then A sends B only global addresses.   If A and
B are communicating using SL addresses (zone x) then A sends B only global
addresses, and SL addresses in zone x, which must be meaningful.   If B
wants to send on the addresses to somewhere else (C) then it follows exactly
the same rule (and drops any SL zone x addresses if the would have to go
somewhere that isn't known to be in SL zone x).

If it turns out that there is no address left to send, then A & C can't
communicate, but that's evidently what was desired when the addresses were
assigned in the first place.   If the administrators actually desire to
prevent hosts communicating, then that's what should be done.

In most cases, there will be global addresses, they'll work, and the issue
of whether some SL or even LL address might also work won't be terribly
relevant.

The info that an app needs to make these particular choices is trivially
easily available, and while it is extra work that apps haven't done before,
it is by no means difficult to manage.

What is needed is that we get beyond the "here is THE address you must
use" methedology, and always allow a set of addresses to be communicated
(either directly, or by sending a name and having the recipient do name
to address translation).

kre

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 Oct 2002 08:08:27 -0400

> Not really, it needs something similar perhaps, but it isn't routing

let's put it this way - it needs information that is currently only 
available to the routing system, and isn't easily provided to hosts
in any case.

> And in any case, this is true any time there are multiple

before IPv6 it has generally been sufficient if all addresses worked
well, most of the time.  one reason we didn't use multiple addresses
as a means of providing redundant access in IPv4 is that it didn't 
work well - despite that, we somehow expect it to work well in IPv6.

> We still do, nothing has really changed.

false.  now we are expecting apps to make sense of a hodgepodge of
addresses, some of which work only ephemerally, others of which 
are ambiguous, others of which work only in certain portions of
the network.  we're even saying that it's okay to expect apps to
deal with hosts that only have addresses that are impaired in 
one or more of these ways -  and apps have no way of knowing
which addreses will work from a particular host at a particular time.

> lots more addresses, and v4 or v6, name to address bindings don't last

you might think of this as just a difference in degree, but it's 
a huge difference.

> them at a local level is sufficient.

apps don't recognize topology boundaries - actually apps are routinely
expected to work across topology boundaries.

> no, we don't need to solve the hard problem to make them useful.

yes, they can be useful - the question is whether they are worth the
cost.  the answer is no.

> somewhere that isn't known to be in SL zone x).

you're being overly simplistic.  A and B don't have any idea whether their
addresses are going to be used, whether or not they'll be used in a zone
where they mean the same thing to nodes there that they mean to A and B. 
that and you're expecting applications to absorb a great deal of additional
complexity for a very marginal gain.

> prevent hosts communicating, then that's what should be done.

it's bad architecture to try to use address bits to indicate whether 
hosts are restricted from communicating.  if hosts aren't supposed to
communicate, the right solution is to block their communication at 
firewalls, not to expect every host/app to maintain a large 'key ring'
of addresses.

> of whether some SL or even LL address might also work won't be terribly

seems like a dubious assumption given the way that SL and LL are being 
promoted.

> it is by no means difficult to manage.

as a writer of distributed apps, I emphatically disagree.
 
> (either directly, or by sending a name and having the recipient do name

what is needed is to actually understand the implications of what you 
propose.  I've tried to write code to do this, and it's really difficult.

Keith