> I would argue the opposite; people won't turn it on otherwise, > due to lack of knowledge or negligence. What I would also argue is > that the API that opens a session should try all available > address pairs in relatively short order - on the order of > tens of milliseconds between new attempts Internet protocols historically have had good scaling properties on widely varying bandwiths and RTT times. Short probe intervals will cause difficulty if RTT isn't also in the order of tens of milliseconds. There's places (I was in one only 2 weeks ago) where RTT to USA was 400 ms, unless we were on backup vsat, in which case it was 2-4 seconds, with congestion and packet loss. And they pay a lot more for bytes transferred than we're used to. Not all the world has low latency and high bandwith. Adding a dependency on this in IPv6 will not help acceptance. IMHO, there's 2 issues: 1. Global IPv6 connectivity doesn't exist - at best, it's a tunnel mess with bits and pieces continuously falling off, then getting reconnected again, and nobody seems to care - there's no effort to make connectivity more stable 2. A new client query type - AAAAA - (that's 5 A's, meaning "give me IPv6 unless it doesn't exist, in which case return me IPv4), with this result cached, would be helpful in high-latency situations Geert Jan _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf