According to this post there were plans to enable IPv6 by default back in 2017. As far as I can tell the change never occurred. The only domains that are serving IPv6 are 2.< name >.pool.ntp.org domains.
Any idea why the change was never implemented?
Hi @imcdona
Mostly just that I haven’t gotten around to do the work to generate the zones in a smarter way to handle the underserved ones. I don’t want to make the service worse by serving the clients AAAA records if there aren’t enough IPv6 servers but would have been enough IPv4 servers, for example.
@ask That makes sense. I’m curious though, how are you going to determine the demand for IPv6 NTP servers without actually making the switch? Do you have DNS stats that indicate the number of requests for AAAA records on the the primary zones?
Maybe we can start testing by zones with more ipv6 servers than ipv4 servers, like tw zone. 
Even in Q4 2018 I wouldn’t expect majority of queries come over IPv6: https://www.google.com/intl/en/ipv6/statistics.html
Right now one of my CZ servers is getting around 700qps over IPv4 and 50qps over IPv6.
In fact some tw servers are mis-categorized hence reducing tw zone capacity. Some guy (maybe) inside Yahoo! registered these servers, but the ipv4 address of t1.time.tw1.yahoo.com and t2.time.tw1.yahoo.com are both categorized as from sg. You can confirm this by traceroute through Hinet, largest ISP in Taiwan. Correct this and the poor tw zone will become healthier.
I have two servers (mistakenly categorized under CN zone). Each gets between 200-1500 qps over IPv6. Seems to me though IPv6 adoption is pretty low in Asia percentage wise, the sheer amount of computers still makes the qps looks significant.
Once again, I would like to suggest the pool Admins consider testing ipv6-as-default config on jp and tw zones. Both have more than one fourth of ipv6 usage, and currently have more ipv6 servers than ipv4 ones, so it should not hurt at all.
mlichvar posted a chart on another thread that had some stats for both IPv4 & IPv6, seeing as how the 6 requests are just a fraction of 4, maybe add AAAA to another one of the pool hostnames (3 would be logical), see if we can bump up usage a little?
There seems to be about 1/2 the number of v6 vs v4 servers on each continent. Of course the overall bandwidth settings is an unknown but I bet the v6 pool is underutilized.
AFAIK in tw major ipv6 clients are coming from mobile carriers, and I doubt if those handheld client devices will query 2.tw or 3.tw hostnames.
Speaking for myself, my IPv6 servers receive way less traffic than my IPv4 servers, but if I started getting much more IPv6 traffic, I would have to lower my speed settings until I received a similar total amount of traffic (with a higher proportion of IPv6 because I like IPv6).
(How’s that for a run-on sentence?)
Same here, way less traffic on IPv6, though I also think it would be nice to have more on IPv6. I see less overall jitter in RTT’s on IPv6 on both of my systems, so they should in theory be able to provide slightly better time over IPv6 than they do over IPv4.
It’s 2019 now.
One of my NTP servers in Czech Republic (which also receives portion of NTP trafic from Germany) is getting only around 10-15% of the traffic over IPv6.
Please pull the trigger this year.
The jp and tw zones have been near one year for constantly having more ipv6 servers than ipv4 servers.
https://www.pool.ntp.org/zone/jp
https://www.pool.ntp.org/zone/tw
Yes, let’s add AAAA-records to all pool-instances, instead of just 2.pool.ntp.org. I can think of no reason at all to not do this. Can you?
I noticed that on the CentOS 8 installs I’ve done they’re using a single pool statement rather than multiple server lines in /etc/chrony.conf
What’s interesting is that they’re using the IPv6 capable pool address 2.centos.pool.ntp.org instead of say 0.centos or 1.centos.
I wonder if IPv6 had anything to do with their decision to use 2.centos?
The chrony config in previous versions of CentOS looked like this:
server 0.centos.pool.ntp.org iburst
server 1.centos.pool.ntp.org iburst
server 2.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst
Correct me if I’m wrong but when using the server option instead of the pool option that config would only ever resolve 1 IPv6 NTP source.
The chrony config in CentOS 8 looks like this:
pool 2.centos.pool.ntp.org iburst
The new config using the pool option with 2.centos.pool.ntp.org has the potential to resolve multiple IPv6 NTP sources as opposed to a single source.
I wonder if we’ll see an increase in IPv6 NTP traffic?
In case you’re wondering, CentOS 8 was released on September 24th 2019.
I believe @mlichvar maintains the Chrony package, he could probably chime in on the changes and rationale.