In message <01OCC10B11TC00ZUIL(_at_)mauve(_dot_)mrochek(_dot_)com>,
ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com w
rites:
On 02/23/2012 14:48, Ned Freed wrote:
On 02/23/2012 13:51, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com wrote:
Old news perhaps, but an unavoidable consequence of this is that the
oft-repeated assertions that various systems have been "IPv6 ready for
over 10
years" don't involve a useful definition of the term "ready".
The OP specified "IPv4 only network." I suspect that if he had IPv6
connectivity his experience would have been quite different. I happily
use Windows XP on a dual-stack network, for example.
And systems running these old OS versions never under any circumstances
m
ove
from one network to another where connectivity conditions change.
Riiight
.
Brian already covered "unconditional prefer-IPv6 was a painful lesson
learned," and I'm not saying that those older systems did it right. What
I am saying is that for most values of "IPv6 Ready" which included
putting the system on an actual IPv6 network, they worked as advertised.
Which brings us right back to my original point: This definition of "ready"
i
s
operationally meaningless in many cases.
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.
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.
No one expect a disconnected IPv4 network to work well when the
applications are getting unreachable addresses. Why do they expect
a IPv6 network to work well under those conditions?
First, you're comparing apples and oranges. Losing all network connectivity is
very different thing from losing partial network connectivity. Nobody expects
an applications that's totally dependent on the network to work without
connectivity. That's just silly.
But with other sorts of applications, I *do* have that expectation. I often
work from places without any network connectivity using applications that
employ networking as part of their function but also do non-networked stuff,
and pretty much without exception they handle the transition fine, and have
done so for years.
Then again, I use a Mac. I have no idea what the state of play of Windows or
Linux apps is in this regard.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf