Subject: Re: source address selection revisited

From: Aleksi Suhonen <[email-masked]>
Date: Fri, 04 Sep 2009 06:41:33 +0300

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

Thanks, I'll look into that.

 > [deleted my own post here]
> I'm afraid the latter change for getaddrinfo() might be also troublesome 
> for some applications.

Hmm ... you may be right. Can you give me examples where it could lead 
to failure?

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

RFC3484 et al. defines the default ordering of the addresses as well as 
some guidelines for letting admins configure the ordering.

All valid source addresses for a given destination address
  (aka "CandidateSource(A)" in RFC3484 section 4)
should be given to the calling application. The most preferable source 
address should be first and the least preferable source address should 
be last. RFC3484 section 5 discusses this ordering, and my post assumed 
that the whole list after the algorithm completes is passed to the 
calling application, instead of just the first address.

-- 
	Aleksi Suhonen, Research Assistant
	Department of Communications Engineering
	Tampere University of Technology