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. 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? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf