Thus spake "Keith Moore" <moore@xxxxxxxxxx>
Well, a start would be a "connectbyname()" API call that takes
care of name-to-address mapping and trying different
addresses until one works.
Most IPv6-capable apps seem to implement that logic now. And
in my experience, it sucks. Really hard. The app can take a
very long time to establish a very poor connection. The specific
reason tends to be that the destination and source both have IPv4
and IPv6 addresses, and the IPv4 address works better than the
IPv6 address (maybe because of 6to4 relay routers or whatnot),
even though the v6 address is chosen first.
Don't forget that you may have a half-dozen or more IPv6 PA addresses that
_all_ have to be tried before the host is going to give up and try the v4
address(es). ULAs and LLAs also fit in there somewhere, as do 6to4
addresses, Teredo addresses, VPN connections, etc. Worse, the other host
has just as many addresses as you do, with the same variable connectivity
for each. You can _easily_ end up with 100+ combinations to probe.
Murphy's Law says that the only address pair that works will be the last one
that your "address selection" algorithm determines, no matter what algorithm
you pick. If you fix the algorithm, fate will respond by changing
reachability so that the new "last" pair to probe is again the only one that
works.
But this is just an instance of the general case that some
source-destination address pairs work better than others.
Address selection heuristics don't do a good job solving this
problem - to solve this problem the network actually needs to tell
the host which source-destination address pairs will work well.
(and that's pretty ugly)
Yes, it's ugly, and it's not the only solution. Another is for the client
to initiate connections from every possible source address to every possible
destination address at the same time, and for the transport protocol to
support adding and removing L3 addresses from the connection over its
lifetime as each host gains/loses prefixes. Good luck deciding which of the
N*M paths to send payload packets over for optimal throughput, latency,
reliability, and cost (among which the stack will likely have no indication
of prioritization from the app). And, of course, that'll entail a
substantial rework of TCP and most TCP stacks, which means it's at least a
decade away. What are we supposed to do until then?
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf