El 11/05/2006, a las 12:10, David Woodhouse escribió:
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.
but my point is that there is a scenario that may be quite common where
similar problems occur, the case of multihomed hosts that have multiple
gloabl addresses. This scenario includes both the case of a host with
multiple interfaces and the case of a host with a single interface
within a multihomed site which obtains multiple PA prefixes from its
providers. In this case, the problems are very similar and they are no
so easily fixed (because you need also to retry with different source
addresses in some cases)
so an approach as the one suggested by Fred would address all this
family of cases that imho would be relevant in many cases
(of course alternative approaches could be defined also, but my goal at
this stage is to acknowledge that this is an issue)
regards, marcelo
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
--------------------------------------------------------------------
