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