Some applications MAY prefer one address over another, but most applications will not care. IMHO the best solution is to allow the OS (and therefore presumably the admin) to specify a default policy, but let applications provide "hints" to the OS that other addresses may be better in certain circumstances. Of course, the OS should be free to not select an address if it is so configured.
In most cases, a default of preferring any IP address in the same /48 as a destination will work, followed by addresses in the same /8, followed by any globally-reachable address. I'm not convinced that such an API is immediately useful, however, since it seems to assume a prior means of determining which addresses will work at all. Most applications will be faced with a scenario where the source has N addresses, the destination has M addresses, and it won't be clear which of the N*M combinations will work without testing them all. Only when there are multiple _working_ combinations does an address selection policy matter. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ----- Original Message ----- From: "Keith Moore" <[EMAIL PROTECTED]> To: "Brian E Carpenter" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, 05 March, 2004 13:29 Subject: Re: Adopt Address Selection API as a WG document? > these choices MUST be made by applications, not by a separate policy > mechanism, because some applications cannot work unless the right kind > of address is assigned - and the OS cannot be expected to guess what > kind of address the application needs. > > or to put it another way, if the policy is to say "you are not allowed > to use a public address" - the proper thing to do is to return an error > to the application that requested this kind of address so that it can > print a message to the effect "local network policy prevents this > application from working here" NOT to give the application an address > that doesn't suit its needs. > > one of the tragedies of NAT was that the policies enforced by NAT are > not visible to the applications or users - so the apps get blamed for > the problems that the policies (implicit in NAT) cause. we need to > not repeat that mistake. > > so we certainly do need such an API. however it's been too long since > I read this draft so I'll stop short of recommending _this_ API until > I've managed to reread it. > > Keith > > > > I don't disagree, and I didn't mean to imply that this is relevant > > to multihoming. But in practice I think these choices will be made > > by a separate policy mechanism, not by individual applications. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
