Re: source address selection revisited

[Arifumi Matsumoto <[e-mail]>]

Hi,

FYI, I remember M. Bagnulo were working on similar problems
related to source addresse selection mechanism, which is
described in the following expired document.

http://tools.ietf.org/html/draft-bagnulo-ipv6-rfc3484-update-00

further comments below.

>
> This got me thinking, and here are some of the ideas I've had so  
> far, in random order:
>
> A) The data structure returned by getaddrinfo() doesn't have any  
> source address at all. In essence, it is source address agnostic.  
> The addresses returned by it are usually given to connect() calls,  
> typically with IN6ADDR_ANY as the effective source address.
>
> The API[3] doesn't specifically state how connect() should choose  
> the source address in this case. So if the implementation of  
> connect() went ahead and tried all "CandidateSource(D) addresses"  
> according to a new address selection algorithm, instead of just one,  
> this would not violate the API[3]. This would be only valid for  
> stateful transports (like TCP) and doesn't work very well for  
> stateless transports (like UDP), where such decisions would have to  
> be made on a higher protocol layer...
>
> B) The getaddrinfo() call could in theory return the same  
> destination address several times if there are several source  
> alternatives for it. The implementations of connect(), sendto() and  
> sendmsg() could then use a different source for the different copies  
> of the destination address.
>
> Could the ai_addr field in struct addrinfo be used to carry some  
> extra hidden information that would tell connect() et al. which  
> source address to use? Otherwise they would have to try to recognize  
> them by pointer address.
>
> Of course, if the application does something to upset these  
> attempts, like bind()s the source address or copies only parts of  
> the ai_addr structure somewhere else, then we can always just give  
> up and use a single source address. That's what the application  
> probably wanted anyway...

I'm afraid the latter change for getaddrinfo() might be also  
troublesome for
some applications.

As far as these are new APIs, they are nice to have,
just like winsock's newly defined APIs like WSAConnectByName().

However, what I'm afraid is that I do not see the specific and  
reasonable
separator for which addresses should be given to the application as the
candidate source addresses, and which addresses should not be.

For example, getaddrinfo() API should treat 6to4, Teredo, ULA and link- 
local
addresses as the candidate source address for a given destination  
address,
and return all the pair of source addresses and destination addresses to
the calling application ?

If we define this separator should be configurable, what should be the  
default ?


--
Arifumi Matsumoto
   Secure Communication Project
   NTT Information Sharing Platform Laboratories
   E-mail: [e-mail]