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