On 2012-02-24 12:32, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com wrote:
In message <01OCC10B11TC00ZUIL(_at_)mauve(_dot_)mrochek(_dot_)com>,
ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com w
rites:
...
I contend that OS are IPv6 ready to exactly the same extent as they
are IPv4 ready. This isn't a IPv6 readiness issue. It is a
*application* multi-homing readiness issue. The applications do
not handle unreachable addresses, irrespective of their type, well.
The address selection rules just made this blinding obvious when
you are on a badly configured network.
That's because the choice has recently been made that the place to deal with
this problem is in applications themselves. I happen to think this is an
exceptionally poor choice - the right way to do it is to provide a proper
network API that hides network selection details, rather than demanding every
application out there solve the problem separately.
I wish, I *really* wish, that it worked. Making it work, by one technique
or another, is not a new topic, even when only IPv4 connectivity
was at issue. Those things are often called 'connection managers'
and are largely based on trial and error or reachability probes.
Then there are efforts like SCTP and MPTCP to solve it in the transport
layer, and shim6 to solve it in the network layer (for IPv6 only, but the
issue is the same). These solutions are also essentially based on
trial and error, and need to be supported by both hosts.
And yes, I'm familiar with the line of reasoning that says applications are
too
varied in their needs, or their internal environments conflict with the
necessary use of threads, or whatever. I don't buy any of it. Yes, such
applications exist, but like most things there's a sweet spot that solves a
significant fraction of the problem.
That's been part of Java for some years (since 1.5 iirc). But it
*doesn't* solve precisely the problem that Martin was describing,
where a stack falsely believes that it has IPv6 connectivity but
in fact it doesn't. In that sort of situation, short of manual
intervention, something like happy-eyeballs seems to be needed in
order for the application to fix things up when the network layer
is confused.
And no, I'm not happy with this, but it seems to be reality.
Brian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf