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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
