Am 12.03.13 22:48, schrieb Markku Miettinen:
This is absolutely the way that a client SHOULD NOT work and this is what many OS and application developers with IETF have been trying to shoot down for years. It is not how IPv6 works as stated one of latter e-mails.
No no no. It works exactly as designed, and in support of all relevant IETF RFCs. It's really the RFCs which are to blame here, not ntpd.
First of all, virtually all applications ask for all entries, both v4 and v6. After that it is practically always the configuration of the OS-level resolver service to return what ever they are configured to.
And so does ntpd.
All reasonable OSs do nowadays prefer Local addressing>NativeIPv6>NativeIPv4>TunneledIPv6. (That is not it all I know, don’t get into that please). DNS queries are done separately, but practically always they go to save DNS server and are returned in the same order in a reasonable time. It is anyway hidden by the resolver, so it actually is not relevant in this at all.
And that is what will happen to ntpd as well.
Second of all, the IETF has worked on e.g. something called “Happy Eyeballs”, which could and should be implemented for abstraction layers like Java-platforms, Qt (which actually has have it for some time already) etc, and applications. Anyone interested may read more, but let me explain the idea: Client launches both v6 and v4 sockets with reasonable delay to prevent additional traffic. This is already sort of an art to define the delay, but in principal one could favor either IPv6 or IPv4 with this. Main purpose of this is to prevent “broken IPv6”-syndrome and simultaneously the service level increases as there is a way around both broken IPv4(!) and IPv6. Also extensive delays in either of the connectivity networks will be mitigated with this. So it’s not just to promote IPv6, but to increase service level of all of the applications!
Please understand that our issue is *npt* broken IPv6 configurations, tunnels, and that like. That may happen *on top* of the fundamental concern that we are talking about:
For ntp, roundtrip time is fairly critical, so you need to find a server topologically close to you. With the current set of servers,
people may find an IPv4 server really close to them, but the nearest IPv6 server might be in Europe, i.e. on a different continent. In this case, the IPv6 server will be readily available, connectivity may be fairly good (as good as it would be when using IPv4), and *still* the quality of NTP is reduced when using IPv6.
In my experience IPv6 outages are way over exaggerated, there are similar things happening in the IPv4 all the time and there is no special buzz about it anywhere.
It's *not* the outages that are of concern here. Regards, Martin _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
