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