It will take some time before IPv4 fades out.
For a quick impression, you can also leave IPv4 on and use my little tool: ntptraf2.
My reply in the other thread might be relevant here, too: Intention to enable IPv6 by default in 2017 - #72 by ask
4 Likes
I have been quite frustrated over the years that my IPv6 address for my server, which is only used for NTP, gets so much less traffic than the IPv4 address that is shared with all the other services. My IPv6 entry is set to full speed, while IPv4 is only set to half, but I still get more than five times as much traffic via IPv4.
In my view, my IPv6 configuration is how I want my server to look, with each service having its own address and the correct DNS reverse lookup to match the AAAA record. All the ugly IPv4 stuff, using multiple A records that point to the same address and thus being forced to have my NTP server show up as my mail server on IPv4 clients (because you need a PTR record with the same name as the A record for mail to work properly, and getting an additional IPv4 address would be prohibitively expensive), is what I have to endure to serve those who still did not manage to get their IPv6 working, or who are stuck behind the routers of those who did not.
For my home network, I have long been forced to only use the one pool address that actually delivers AAAA records, and add some fixed addresses to the ntp.conf as well. For many customers of the big providers in Germany, IPv4 already uses NAT in the carrier’s network, and only IPv6 is directly routed to the home network. Sharing one IPv4 address with thousands of other customers leads to a lot of trouble with rate limiting, and unfortunately also quite often to severe jitter in the round-trip time.
I think not only should there be AAAA records added to the replies of at least one additional hostname in all the zones that contain enough IPv6 servers (like e.g. *.de.pool.ntp.org), there also should be some AAAA records in the replies of pool. Everyone who does not want to use IPv6 can still use “server -4 pool.ntp.org iburst” in their ntp.conf to ensure only the IPv4 addresses are resolved.
Unfortunately, the opposite “server -6 …” does not work with pool right now, and as long as it only works with 2.*, there is no way to get more than four initial IPv6 addresses for the client to chose from. That is not enough, because there can always be a few servers that are reached via really crappy routes in that initial reply. If AAAA records were added to e.g. 3.*, users would at least have a way to get eight initial IPv6 addresses to chose from, which would finally make the pool sufficiently robust for those w/o proper IPv4 connectivity.
So please, go ahead and add AAAA records to 3.* in the regional pools that have enough IPv6 entries! This really should have happened years ago.
2 Likes
In my opinion the pool.ntp.org should serve more then just 4 adresses, 6 or even 8.
Serve 4x IPv4, like it is now and serve 2~4 extra IPv6 addresses.
This is no problem, then IPv6 systems do get resolving too if they ignore/block IPv4.
I mean, I serve my own pool:
nslookup ntp.heppen.be 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: ntp.heppen.be
Address: 5.196.189.119
Name: ntp.heppen.be
Address: 89.207.129.63
Name: ntp.heppen.be
Address: 5.135.125.103
Name: ntp.heppen.be
Address: 212.187.8.48
Name: ntp.heppen.be
Address: 77.109.90.72
Name: ntp.heppen.be
Address: 2a00:7b80:477:21::9dcb:d174
Name: ntp.heppen.be
Address: 2a02:578:440e:0:5f05:fa04:1720:d90f
Name: ntp.heppen.be
Address: 2001:41d0:203:654d::8f37:5630
Name: ntp.heppen.be
Address: 2a02:578:440e:0:aaa1:59ff:fe3d:5b53
No issue at all. @ask could easilly make a request generate more then 4 IP’s.
BTW: I created an issue on FeeBSD tracker as I noticed that current ntp.conf does not allow IPv6-only access. (by only using 0.freebsd and not 2.)
3 Likes
It’s 2024.
At the very least, can we get ipv6.pool.ntp.org or similar?
No need; we have 2.pool.ntp.org that does IPv6. All that is needed is to add AAAA-records to (some) of the other ones as well.
Let there be no mistake:
The NTP pool is diligently maintained by @ask. However, the NTP pool wouldn’t be possible without the dedication of hundreds, if not thousands, of volunteers contributing servers. With 63% of these servers reachable via IPv6, the ‘NTP community of volunteers’ sends a clear and unmistakable signal that it wants the pool to support IPv6. It would only be fair if their wish were granted.
This can simply be achieved by adding more AAAA-records in the DNS of pool.ntp.org. It was extensively substantiated in many posts on this forum that this can be done without any operational risks.
5 Likes
Maybe they actually meant specifically an IPv6 only zone? Some websites have IPv6-only subdomains to force IPv6. That’s useful for troubleshooting, and potentially, serve as some kind of workaround for some users. If it makes sense for the pool to have this, up for discussion I suppose. Could be someone’s IPv6 connectivity is more stable than their IPv4, especially if they’re behind CGNAT/NAT64
1 Like
I strongly support expanding IPv6 support from the Pool based on the fact that IPv6 adoption is continuously increasing worldwide.
2 Likes
In my opinion the pool should be mixed in all section.
As you can use more then just 4 IP’s at the same time, depending on the DNS server.
nslookup ntp.heppen.be 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: ntp.heppen.be
Address: 77.109.90.72
Name: ntp.heppen.be
Address: 89.207.129.63
Name: ntp.heppen.be
Address: 5.135.125.103
Name: ntp.heppen.be
Address: 212.187.8.48
Name: ntp.heppen.be
Address: 2a02:578:440e:0:aaa1:59ff:fe3d:5b53
Name: ntp.heppen.be
Address: 2a02:578:440e:0:5f05:fa04:1720:d90f
Name: ntp.heppen.be
Address: 2a00:7b80:477:21::9dcb:d174
Name: ntp.heppen.be
Address: 2001:41d0:203:654d::8f37:5630
Why mixed and not separated? Well simple, people that travel a lot do not always have IPv6 addresses to use. IPv4 is always there.
As such if they set IPv6 only, they could see their clock go wrong.
A friend of mine travels al lot all over the world, often starved of good internet, so he must depend on what he’s delivered.
As such I would see a mixed resolving, there is no problem doing this.
E.g. 3 IPv4 servers and 2 IPv6 servers, so everybody gets enough servers no matter the protocol.
Just 2 IPv6 servers, just to not overload the IPv6 servers with traffic, can be adjusted later on when more data is known about requests.
From my understanding, if someone’s behind NAT64, the ISP’s DNS server will put IPv4 addresses inside a designated IPv6 subnet and change it to a AAAA record, which means the client can’t tell what’s IPv4 and what’s IPv6 since they all appear to be IPv6. In that case, having an IPv6 only zone to force native IPv6 could make sense. But that would be a specific “ipv6.pool.ntp.org” and not any of the numbered zones imo.
If you refer to DNS64: this only happens if there is no AAAA-record present.
Thus, 0.pool.ntp.org would return something like 64:ff9b::c200:57b (for 194.0.5.123), which is artificial, whereas 2.pool.ntp.org returns a real IPv6-address like 2001:678:8::123. In other words; 2.pool.ntp.org will never return the artificial DNS64 address.
Try for yourself:
dig +short AAAA 2.pool.ntp.org @dns64.dns.google
Obviously, if you want, you can also ask for the IPv4 address:
dig +short A 2.pool.ntp.org @dns64.dns.google
Hence, if all pool.ntp.org names are configured with both an A and an AAAA-record, it will probably all work just fine; (real, native) IPv6 is ‘forced’ by default, so to speak.
So, I agree with @bas.heijermans on this.
I could live with his suggestion to perhaps start with fewer IPv6 and gradually increase, based on data - as was suggested by @avij back in '21. But the desired ultimate situation should be dual stack everywhere; A and AAAA-records on all pool.ntp.org names.
There is quite a lot NAT64/DNS64 nowadays, by the way. So providing this ‘mixed’ setup, as Bas calls it, really makes sense.
5 Likes
What a thread !
I found it because I had an issue with my IPv6-only node.
I finally sent an issue on github
2 Likes
What is the current situation about this?
Are there still real reasons against enabling AAAA records for all pools?
4 Likes
I don’t think so.
In fact, there are actually good reasons to turn it on, like these (and many others) have done:
time.nist.gov
time.facebook.com
time.apple.com
time.google.com
time.cloudflare.com
time.aws.com
ntp.ubuntu.com
ntp.se
I’m pretty sure there are reasons, but I would love to see them spelled out.
One reason that comes to mind is that some clients behavior will change. I’m guessing there are clients out there that will be negatively impacted as they don’t have working IPv6 but the software will nonetheless displace IPv4 servers with IPv6 ones.
There may be some, unsignificant quantity of such broken clients or there may be none. This fear isn’t enough justification to stay forever where we are now.
3 Likes
Broken clients are out there for every protocol.
Is that a reason for Google, Meta etc. not to enable IPv6?
No.
If there are still broken clients, people will notice and hopefully tell the developers about that. Not enabling it because of the fear that some minority using broken software will complain means no change at all forever.
5 Likes
I do worry about the sudden shift in traffic towards IPv6 servers, but that’s unavoidable. I imagine sure there will be a few surprises and some server operators may have to adjust their net speed but it ought to work out in the end.
3 Likes
It is possible to add gradually. For example add first the AAAA records to 1.pool.ntp.org, then a bit later to 0.pool.ntp.org, after a while 3.pool.ntp.org , and the last is pool.ntp.org. Check the load on the IPv6 servers in between.
5 Likes