On Thu, 2006-05-11 at 09:53 +0300, marcelo bagnulo braun wrote: > right, but i guess it should be possible to define some heuristics to > reduce the number of attempts since it is likely that several of those > addresses have the same reacahbility status.
RFC3484 is a defined set of heuristics which reduces the number of initial attempts... to one. It _works_, in general -- it just needs fixing for the corner case Pekka and I described. That fix is as simple as an extra line in the default label/precedence table. It was (is) hard and slow enough getting applications to adapt to getaddrinfo() and RFC3484. I don't think it buys us much to talk of another change now... especially one which involves multiple simultaneous attempts to connect, then just discarding the connections which are slower to respond. In today's world of tunnels, that solution would share the problem that glibc's existing 'favour IPv4 unconditionally' solution has -- you'll end up using IPv4 instead of IPv6 a _lot_ of the time, and IPv6 will get very little use or testing. My ISP may offer native IPv6-in-PPP on my DSL line, but that's unfortunately the exception rather than the norm, and the IPv4 connection is usually going to win the race against an IPv6 connection which goes through tunnels. -- dwmw2 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
