> 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. one question here is whether there is some burden on applications to try to find a path between hosts B and C, say by address and/or interface selection, or whether the burden is entirely on the network. one of the problems with our current notion of 'policy domains' is that they are so inflexible as a security mechanism that people demand, out of necessity, that some applications be able to work across them. so no, it's not reasonable to assume that apps that do referrals are only expected to work within a single policy domain. > 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. that's because you haven't had to deal with DNS unreliability, imprecision, inconsistency, and performance issues. > 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 not in a general sense. even today, the vast majority of IPv4 hosts have a distinguished IP address that is usable from everywhere that's supposed to be able to talk to the host. > , 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. which is a management nightmare. > 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. no, but when the connection times out right after the host has received 3 or 4 "prohibited" ICMP messages in response to traffic sent on that connection, it's a pretty good clue. Keith