> The addr-select doc I'm reading contains protocol specification - that > is, if the destination address is X, and A, B C are possible source > addresses, which one should be used. (And of also of course, when there > are multiple destination addresses, ...) That's not API - it doesn't say > a word about where in the stack all of this should be done, nor does > it say anything about the mechanisms that might be used to influence > the choices, where such influence is possible.
One reason I say that this is an API issue is that (at least the destination address selection stuff) is really a mechanism for encouraging or defaulting the binding of the destination address to a socket. But the application is going to need to be able to explictly choose a specific destination address in any case, so this is just a way to help the application choose the "right" answer. Another reason I say this is an API issue is that a good choice of destination address (and therefore source address) cannot be made without explicit knowledge of the application's requirements. One application wishes to maximize privacy by using temporary addresses, another wishes to maximize address stability, another needs global addresses to maximize its potential for access by/to peers. Another reason I say that this is an API issue is that we really need all platforms that currently provide the same API to implement this address selection procedure in such a way that they still provide the same API- e.g. we don't need one socket-based system doing it via a new version of gethostbyname() or whatever it is this week, and and another socket-based system trying to do it via a new version of bind(), and another one writing an explicit select_dest_address() routine. This cannot be a protocol issue except in a few specific cases, because there are very few (approaching zero) protocols that explicitly and exhaustively define the mechanisms by which addresses are advertised to potential peers. e.g. We cannot assume that all addresses in all (or even most) protocols are obtained exclusively through DNS. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
