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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf