Eric Rosen wrote:
... The fact that A gives B an address of C
rather than a name of C doesn't seem relevant at all;
after all, names just resolve to addresses; I think the
name vs. address issue is a red herring in this context.
If A gave the entire list of choices to B, you would be right. The
problem is that A will generally give B the one it chose, since it
believes that one works.
The existence of policy domains seems to restrict the
applicability of these multi-party referring applications,
especially as the app itself has no way of knowing whether
it is crossing policy domain boundaries.
This is right in the general case. We have toyed with the idea of
preventing mixed scope connections which would allow the app to clearly
know.
So what does this have to do with site-local addresses?
I think two
arguments have been made.
1. Because site-local addresses are ambiguous, if A passes
a site-local
address to B, B may not be able to use it to talk to C.
I think the reply that has been made to this is that
the site-local
addresses have to be unambiguous within a particular
policy domain, and
it is a management function to ensure that this is the
case. Since the
apps in questions are applicable only within a policy
domain, the fact
that the addresses are ambiguous outside that domain
doesn't makes the
apps any less useful than they already are.
This is right on.
2. A system with a site-local address is likely to have
other addresses as
well, and it is a bad thing for a system to have more
than one address,
because the apps have no way of knowing which address is
the right one to
distribute.
I think the reply to this is that this horse escaped from
the barn about
20 years ago, and anyway, choice of address is a
management function.
That is, the app needs to be told through some sort
of config which
addresses to use when.
The intent of the sending rules is to provide the default version of
that config. There are arguments that those don't work for the mobile
node case, but I would argue that the mobile node has to know when it is
away from home to inform its HA, so we could add a rule that MNs don't
use local scope addresses when away from home.
It's been claimed that if non-ambiguous addresses are used,
at least the app can tell when communication is being
prevented due to policy restrictions, as it will receive
ICMP messages with appropriate diagnostic information.
Unfortunately, this presumes more from the network layer
than the network layer actually provides. ICMP messages
may be generated due to transient problems, they may fail
to be generated at all (for "security reasons", or due to
limitations on the rate of ICMP generation), they may be
dropped in the network, etc. When communication fails,
there is no reliable way for the endsystems to determine why
it has failed.
In addition, it doesn't solve the issue that A will pass B the address
that it is using, rather than the possible set. B needs to derive its
own view of how to reach C even when globally unique addresses are used.
So I don't really think the case against site-locals has
been made here (which is not to say that there isn't a
case against them based on other considerations).
I think the underlying problem is that our comms
architecture doesn't take the policy restrictions into
account at all, and folks tend to assume that this needs to
be accounted for at some other layer than the one they are
most interested in. This generates frustration, and creates
a high heat to
light ratio. Usually everyone blames it on NAT, so it's
nice to see the
same issue come up in an IPv6 non-NAT context.
I am not trying to place blame, but I would word it differently. While
the architecture has all along allowed for differentiating policy
restrictions, the app community chose to simplify their effort by
ignoring that there were policy differences in the lower layers. This
worked as long as the world was dominated by client/server oriented 2
party apps. In a world of multi-party apps, the policy differences of
the lower layers are exposed and we need to rethink how apps deal with
that reality.
Tony