Olaf, >> let us say we have 5 classes of host implementations: >> >> 1) IPv4 only and those which will never be upgraded with IPv6 support >> 2) partly broken IPv6 support and without DHCPv6 >> 3) partly broken IPv6 support with DHCPv6 >> 4) full IPv6 support without DHCPv6 >> 5) full IPv6 support with DHCPv6 >> >> by partly broken I mean lacking dual stack / IPv4/IPv6 >> multihoming support. i.e happy eyeballs or having other >> serious short comings. I do not want to enable IPv6 on hosts >> implementations that e.g have 75 second timeout to switch >> from IPv6 to IPv4 (well known fruit vendor). > > OBo: Hmm not sure if I understood what "partly broken" means. Have to think > about once more what you are trying to say here.
sorry for not giving more references. basically I'm thinking of a slightly more generalized version of the problem described here: http://tools.ietf.org/html/draft-wing-http-new-tech-01 to cite an example. the host implementation that I am using, has a 75 second timeout from trying an IPv6 connection to trying an IPv4 connection. and while it does A and AAAA lookups in parallel it picks the first reply and that leads to indeterministic behaviour. cheers, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
