... 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.
there are multiple problems.
one problem is when the network expects different hosts to choose
different addresses in order to reach the same destination.
another problem is that even if A passes a list of choices to B,
neither A nor B typically has any idea about which choices will
work for B, or for any third intermediary that B passes the list to.
(no, it's not the case that A will "generally" give be the address it chose,
because there's too much variation in behavior between distributed apps.
often A has no need to choose from that set of addresses at all; it's just
trying to provide some referral service.)
another problem is that being able to pass a list of addresses is not the same
thing as being able to fail over from one address to another, and yet people
want to treat the existence of multiple addresses on a host as a substitute
for multihoming.
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.
another false statement. apps have been expected to deal with crude and
inflexible policy implementation in lower layers for many years, so apps
people are painfully aware that such differences exist. what some of us are
saying is that the lack of flexibility in these mechanisms has increased
complexity in both apps and the network without providing much in the way of
useful policy control or security, and we need to reconsider some of the
cruder mechanisms like private addressing. or in other words - don't create a
mess at layer 2 or 3 and expect layer 7 to sort it out.