On 2012-02-24 12:32, ned+ietf@xxxxxxxxxxxxxxxxx wrote: >> In message <01OCC10B11TC00ZUIL@xxxxxxxxxxxxxxxxx>, ned+ietf@xxxxxxxxxxxxxxxxx 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf