>> For instance, applications in the global finance industry typically do >> not do any DNS lookups at all. Admittedly, they often have a list of >> destination IP addresses which they try until a connection succeeds. But >> the point is that IPv6 transition has to be explicitly programmed into >> each and every application and it has to be embedded in the operational >> processes as well. > > Which is in fact the exact same logic a dual stack application should > follow after calling getaddrinfo(). Whether or not you resolve a name > to get the list of addresses, you need the logic to try all available > addresses in turn. well, it depends on the application. sometimes the delay required to try all of the addresses in turn until one is found to work is not acceptable, and at other times it's very annoying... particularly when the default address selection rules don't predict which (source,destination) address pair is going to work best. > otoh, I've never yet found an application programmer who found upgrading > to the new socket API to be especially challenging; it's just work. the problem isn't the differences between the v4 and v6 socket API. the problem is the expectation that in IPv6 the application has to choose which address(es) to use, coupled with the high probability that the first address(es) chosen will not work well. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf