Hi Ole,
On 10-09-13 05:20 AM, Ole Troan wrote:
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.
While this is a valid problem, this has nothing to do with the issue
that we are discussing. This can be fixed in the following ways without
requiring protocol changes.
* Host based IPv6 tunneling mechanisms with
questionable/intermittent/broken reachability should not be turned on.
* ISPs who do not have upstream IPv6 connectivity towards the content
providers should probably not enable IPv6 for their customers.
Cheers
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
