> In message <01OCC10B11TC00ZUIL@xxxxxxxxxxxxxxxxx>, ned+ietf@xxxxxxxxxxxxxxxxx w > rites: > > > On 02/23/2012 14:48, Ned Freed wrote: > > > >> On 02/23/2012 13:51, ned+ietf@xxxxxxxxxxxxxxxxx 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf