While I enjoy seeing the IPv6 guys arguing with each other, I don't think
that anyone is deliberately spreading incorrect information here.
There seems to be general agreement that there are multi-party applications
in which A needs to tell B to talk to C. Thus A needs to have some way to
unique identify C to B.
However, because of communications policy restrictions, neither the
application layer nor the network layer can know whether B is actually
allowed to talk to C. So it seems that these applications can only work
when deployed within a policy domain. (Policy domain boundaries are
generally marked by such things as firewall and security gateways, things
which are hated by the purists because they eliminate communications
transparency.) 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
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.
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.
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
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.
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.
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
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.