Mark Andrews wrote:
ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf