Sursh, >>>> 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.
I think it does. if your argument is that the access layer has to support SLAAC because of the high number of "legacy" hosts, then my argument to refute that is that you have to upgrade those hosts anyway, otherwise you will have users with blood shot eyes. ;-) > 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. that will certainly help the problem, but not solve it. either the IPv4 or the IPv6 path may be broken at a given time, and having an implementation having the user wait 75 seconds is unacceptable. now, if we agree that legacy hosts will have to be upgraded, it does of course not mean that they will also be upgraded with DHCPv6 support, but at least there is an opportunity for that. cheers, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
