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