Anyway, it is valid to use (obsolete) site-local source address
for global destination address.
The problem seems that router does NOT send ICMPv6 destination
unreachable to the sender. I don't know why, but it SHOULD.
I'll pursue that question later. It wouldn't be _sufficient_ since there
are (buggy) programs, including Evolution, which will not fall back to
the second and subsequent addresses from getaddrinfo() -- they'll just
give up when the first attempt to connect fails. So we really do need
the IPv4 address to be listed _first_ in the results, as it used to be.
Or get the applications fixed no? Kludging around application bugs
sounds a bit like the "Fram Oil Filter" commercial where the mechanic is
grinning while he says "You can pay me now, or you can pay be later." As
in pay for the slightly more expensive oil filter now, or engine repair
later.
I wish to deploy IPv6 internally so that we can develop and test IPv6
support. There is _no_ chance of getting proper IPv6 connectivity to the
outside world through the corporate firewall. I'd like IPv6 to be usable
_internally_ though, without breaking connectivity to the outside world
over IPv4.
How should I do this?
Other than fixing the applications that only take the first response
(isn't that a generic application bug going back nearly decades now?
amazing how things stay the same isn't it) Can you run a caching-only
name server at the edge that filters-out the IPv6 responses so your
systems never see Global IPV6 responses?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html