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