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