In message <20100620195212.4BD395413@xxxxxxxxxxxxxxxxxxx>, Geert Jan de Groot writes: > > 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 And many of the tunnels are not a issue even if it would be better if they were turned into native connections. > 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 It would do *nothing* to help. The client or the libraries it calls can already do this if they want. Making two lookups is not a real issue. You would need to upgrade both clients and libraries to make this change without breaking existing application. Just add a new flag to getaddrinfo() and upgrade the clients to set it. While you are upgrading getaddrinfo() change the sorting order of of the addresses you return and you have addressed most of the tunnel issues as well. Mark > Geert Jan > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf