Subject: source address selection revisited

From: Aleksi Suhonen <[email-masked]>
Date: Thu, 06 Aug 2009 04:18:07 +0300

Hi,

One of my problems with existing address selection implementations is 
that they pick just one source address per destination address. They 
never try another source address even if a valid alternative source 
address existed for a destination address. This has caused me some 
headaches with existing multihomed IPv6 and IPv4 deployments.

I had the chance to talk with Arifumi Matsumoto at IETF75 last week 
about my alternative address selection algorithm draft[1]. I'm 
continuing parts of that discussion here, now that I've had the chance 
to think about stuff. I'm addressing this message to the list at large, 
hoping that someone else is interested as well.

According to Matsumoto, the original default address selection 
algorithm[2] defines the above behaviour that frustrates me. And sure 
enough, while re-reading the RFC, I find where it says so right at the 
beginning of section 5.

Furthermore, Matsumoto said that the address selection application 
program interface[3], culminating in getaddrinfo(), cannot even support 
multiple source addresses per destination address. So any algorithm that 
would result in multiple source addresses for the same destination 
wouldn't be backwards compatible.

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

On the scale of 3 to H, how blasphemous do you think these ideas are?

[1] http://tools.ietf.org/html/draft-axu-addr-sel-00
[2] http://tools.ietf.org/html/rfc3484
[3] http://tools.ietf.org/html/rfc3493

-- 
	Aleksi Suhonen
	Department of Communications Engineering
	Tampere University of Technology

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 13 Aug 2009 19:33:56 +0900

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: [email-masked]