Mark Andrews wrote: > > ned+ietf@xxxxxxxxxxxxxxxxx writes: > > > > Which brings us right back to my original point: This definition of > > "ready" is operationally meaningless in many cases. Correct. > > 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. There was *NO* multihoming involved at all. The OS of my primary workmachine has in IPv6 protocol stack with an extremely bogus design that pretty much precludes any kind of migration and testing. It delays sending DNS A lookups (in favour to AAAA lookups) for whooping 16 seconds to DNS servers for which only an IPv4 address is known over an interface that is IPv4-only with a default route over that very same IPv4-only interface. And even disabling IPv6 on the two virtual network interfaces did not stop that non-sensical behaviour. It just doesn't make sense to send out less DNS A lookups than DNS AAAA lookup, and even less to delay DNS A queries for 16 seconds. The only solution was to rip IPv6 out of the OS entirely. Luckily I had access to the console of the machine, because when requesting uninstall of that (inactive) IPv6 protocol stack, the machine immediately dropped *ALL* networking on all interfaces, ipconfig /all gives an empty list, as if remote administration of servers was a concept completely unknown to the OS vendor. If there is desire for widespread adoption of some new protocol or feature, than it is a very very very very bad idea to create such an extremely misbehaved implementation. And it's not like "this is brand new and we didn't have time yet to fix this bug". -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf