> Is that how we'd want it? I remember there were some concerns about > DNS queries returning (or clients preferring) AAAA over A records.
There are issues, but they very much depend on the client software. For the pool, it's irrelevant - the pool only ever delivers IP addresses, never names (and currently restricts them to v4, anyway). For other services, applications are supposed to either try v4 only (if they use gethostbyname), or fall back to v4 if v6 fails. Typically, v6 fails in one of two ways: - v6 is disabled/not implemented in the client; the application fails to create a v6 socket (and should immediately proceed to trying v4). - v6 is enabled, but the system has no connectivity. The local OS kernel recognizes that immediately (by lack of routing tables), returns "network unreachable", and the application falls back to v4. Unfortunately, there are a few apps (selected minority web browsers) that fail to implement the second fallback. They find that the system supports v6 sockets, and fail to fallback to v4 when they don't get connectivity. There used to be a third case common, but that gets more and more infrequent: - the system has v6 connectivity by means of some very poor tunneling connection. In the early days, some "backbone" routing was done through DSL tunnels, but these should now all be disabled/routed-around. Also, the v6 autotunnels are now more reliable than they used to be, and systems now prefer connectivity in the order "native v6", v4, "tunneled v6". However, this problem may still occasionally happen. Whether these are issues for you depends on your clients. > I > use different names for v4 and v6 services too, and that seems like a > viable way of creating an "opt-in" system for both users and servers. For "manual" services, perhaps (such as remote login, ntp). For "automatic" services (URL based ones, such as http/web servers), this is no viable solution, because it would require people linking to your pages to provide two versions of the page themselves. Regards, Martn _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
