I think we’re getting ahead of ourselves here. First we need to understand if the ntppool.org folks are willing to ever broaden IPv6 beyond 2.*.pool.ntp.org…
@ask ??
1 Like
Please, don’t start the whole discussion over again - this was all already discussed many moons ago:
2 Likes
I don’t think the intention was to reopen the discussion as to the how of the way forward. But rather focusing on understanding as to where the only person who can effect any change in that direction currently stands on the topic.
Without Ask being able/willing to do anything in relation to this topic, any discussion, past or present, regarding the how (how to transition to the new state) or what (what the new state is) is moot.
2 Likes
Purely for information the outcome of some digging I did:
Re-reading what I believe to be the latest post by Ask on this topic, I understand that at that point in time, the following activities were on his to-do list:
- Get the new monitoring system up and running in production.
- “some features for managing the “vendor zones” so vendors can choose if/when they want to upgrade to “full IPv6””
- “change [the vendor zones] so the zones can be configured to fit the needs” of the vendors
- “related features for expediting how the vendor zones are managed”
- “get back to the original plan of making IPv6 the default in all country zones where it makes sense”
Item 1 is done now.
Not on the list at the time, and also done by now, were the features for user information download and user deletion.
I guess the mention of “where it makes sense” in item 5 complements that “some choices [are] to be made around backfilling zones from the region versus not providing AAAA records vs giving out (too) few IPs”. I.e., enabling IPv6 seems not as straight-forward as “just” adding a few digits in the code if some of the issues that exist with the IPv4 zones are to be avoided, if possible, for IPv6.
I guess the server points feature would serve to better understand the traffic for IPv6 as well for informing the aforementioned choices to be made, not just the redesign of the zone concept itself. This server points feature also wasn’t on the list above, at least not explicitly (maybe subsumed somewhere else).
Then, as he previously mentioned at several other occasions as well, Ask’s “time on the project mostly goes to basic care and feeding of the system”, assumedly leaving only the lesser part of his time for major developments, e.g., new features/major enhancements.
So that might shed some light on what is going on with respect to this feature.
Note that this is just my interpretation of available information, his list may obviously have changed further since then, apart from the additions I mention (and possibly others I missed).
Again, this just informatively, as is, not taking any stance on the items, or judging them.
Except that I’d obviously like to see IPv6 enabled on more zones, while at the same time understanding Ask’s constraints and priorities, including keeping the system operationally stable.
EDIT: The server verification feature is another one missing from the list.
1 Like
Thank you for your summary.
Things are indeed probably more complicated than we think. But what @ask had in mind, seems overly complicated to me. As he’s most likely busy enough as it is, with keeping the NTP pool operationally stable, it is probably safe to cut a few corners and simplify his initial plans with regard to IPv6, especially because a lot has changed over the years and IPv6 is now much more common than it used to be.
If it was up to me, I wouldn’t make IPv6 optional (in vendor zones - item 2). Just treat IPv6 the same as IPv4 in the entire pool.
With regard to item 5; some 58% of all participating servers globally, are IPv6 enabled (which is sufficient to handle the anticipated load) and a quick glance shows a similar distribution per region.
Even on a per country basis the figures seem to be looking good, based on some random samples. So I wouldn’t worry too much about this.
If IPv6 is enabled gradually, with sufficient communication towards server operators (and vendors), things should work out fine in my opinion.
2 Likes
Another approach that I have thought of after catching up with the discussion so far is to
- introduce ipv4-only and ipv6-only subzones for all existing pool zones
- alter the vendor zones to use the ipv4-only zones for everything except
2.vendor, maintaining full backwards compatibility - change the pool to distribute ipv6 across all regular zones
- implement the option for vendors to switch their zones to the new system
That way, the “non-vendor”-part of the pool could be ipv6ed without having to implement the new vendor settings beforehand, every step only causes a specific targeted change, and the pool gets ipv4-only/ipv6-only zones in case someone wants to use that. What are your thoughts on that?
Also I share the sentiment that while it would be great to have an improved zoning concept before rolling out IPv6 across the pool, both are independent issues that do not necessarily need to be implemented in that order.
1 Like
For whatever it’s worth, without any comment from pool staff to inform my understanding of the situation, this is my current preference as well.
Just flip on IPv6 and be done with it. To the extent it causes breakage, it’s a one-time breakage and could be preceded by warnings cast wide and far in advance, such as to questions@lists.ntp.org, here, NANOG list, any similar RIPE or ARIN or other RIR lists, various Open Source OS user mailing lists, mailing lists used to reach multiple Linux distro maintainers for coordinated bug fixes, etc.
I know @ask has mentioned planning to make it optional for vendor zones. I think to the extent that is further delaying wider IPv6 pool service use, I would advise dropping that idea and just put this longstanding bump in the road in the rearview mirror. The rest of the net has moved on. You can’t access the full internet if you can’t access the IPv6 internet so many years after IPv4 exhaustion in so much of the world. Bottle-feeding those who would complain that they haven’t prepared for IPv6 after 25 years is not wise in my opinion.
7 Likes
I fully agree.
I assume the amount of broken systems will be rather slow.
If a system doesn’t support IPv6 at all, it won’t care about the new AAAA records.
If a system doesn’t have a public IPv6 address, it won’t care about IPv6.
If a system has GUA addresses, but can’t reach other destinations, networking is already broken an NTP is just a part of that. Such users will notice that something is wrong and NTP won’t make that worse.
5 Likes
I just submitted a Pull Request that simply distributes IPv6 servers across the zones the same way IPv4 servers already are. I look forward to your feedback.
10 Likes
Any update on this? It is already 7 years after the initial target date (2017) of adding IPv6 to the pool. It is really time to handle IPv6 as an equal netizen to IPv4.
- Looking at Google’s IPv6 stats, in 2017 20% of their users used IPv6. Now it is 45%.
- Hosting providers are starting to give an IPv6 address for free, but ask extra for an IPv4 address.
- Because of IPv4 scarcity, CGNAT is growing to the point that adding rate limits and KOD on your NTP server is hurting valid users more than anything else.
- Many distributions now ship with (the secret) 2.xxx pool configuration lines because the lack of IPv6 addresses on the other names are hurting enough of their users.
According to the global pool stats, there are 1710 IPv6 and 2999 IPv4 servers, so given that the whole world has not completely moved to IPv6, that should be enough to handle the load.
BTW I think the line “Global — pool.ntp.org (4325)” on the global zone stats page is a little misleading, given that that name only hands out IPv4 addresses. 
4 Likes
@Bas
You already trolled in the past and your last post still contains pure nonsense and entirely stupid questions.
If you hate IPv6, don’t use it and simply leave this discussion, a change here won’t affect you anyway.
If you ask the question why DNS needs a separate record for another address type simply proffs that you are completely clueless regarding DNS and the common way stuff is specified and handled by software
For the others who want to know and are able to understand:
A (used for IPv4) can’t be used for anything else because clients requesting it expect exactly an IPv4 address and nothing else.
That’s why different record types exist in DNS.
7 Likes
This exactly proofs that you are entirely clueless and fact-resistant. I explained why this doesn’t work by design.
Why do you keep repeating the same BS ideas?
5 Likes
I think it’s preferable to flag posts with what you feel is wrong with them rather than just argue back and forth. I mean if there were some actual debate here, fine, but in this case no one’s opinion will be changed no matter what is said.
3 Likes
Agree, no point of arguing on question of taste. One likes, other does not like that is the way how the life is.
I never seen anything from you that explains why it should be such a stupid protocol.
IPv6 may have been a good idea at the time, but today when computing-power is not an issue, it’s rubbish.
Many things could have been changed to the better.
It didn’t. It’s still crap like it was 1998…
It’s a design from an era where when computing-power was expensive.
It needs redesigning to modern days. For some reason it’s not better in 2024!
26 years later…still crap. It doesn’t take much to improve it as it’s still not widely accepted.
And it never will if they keep up the old rubbish.
It has good points…but the implementation is a nightmare and shouldn’t be this way today.
AAAA and A record can be merged into 1, there is no need to keep them seperated.
MX-records, don’t exist in IPv6, why not? Let people decide themselves.
etc.
IPv6 needs rework…it’s old, poor design and not modern. Designed in the stone-age by idiots.
As such so much fails on modern systems, one example being the pool.
Intelligent people know that MX records contain a domain name and not an IP address. Please read the RFCs before spreading just plain BS.
A domain name can itself contain multiple records. That’s why MX needed no change. But only intelligent people will be able to learn this. 
Back to the topic (Bas, we don’t need your “expertise” here):
Are there still real scenarios where adding AAAA records to the pool addresses could create big failures?
3 Likes
More precisely an MX record points to a hostname. There is syntactical restriction on hostnames, for example underscore is not permitted. Also only A and AAAA records are permitted, for example an MX record cannot point to a CNAME record.
3 Likes
I tend to disagree. SNTP requests are made with intervals, like on the top of every hour (it’s even visible in the DNS statistics of the pool, if you look closely). When many IoT-devices in a network behind CGNAT do this at the same time and they receive the same set of IP addresses from the local resolver, say for 0.pool.ntp.org, and try to connect to them all at once via IPv4, there are rate limiting issues possible, just as @john1 rightfully mentioned.
It’s the internet’s way for clients to indicate that they understand (and prefer) IPv6, just as you suggested in another post in this thread.
What kind of records would you have in mind? 
NAT is possible, but not really needed. NAT was invented to deal with a shortage of IPv4 addresses. Such problems do not exist with IPv6.
My home router works exactly like that - out of the box. However, that future is called; ‘firewall’ and not; ‘NAT’.
Multiple IPv6 addresses on an interface can indeed be observed at clients and there’s a (rather long) explanation for that - something with auto configuration and privacy. However, it is extremely simple to configure just one single IPv6 address, like I do on all my servers (with netplan in my case), just as I do for IPv4.
Everyone is entitled to their own opinion, but your ‘hate’ against IPv6 appears to be based mainly on simply being ill-informed, rather than being based on facts.
6 Likes
No.
Or perhaps…
Nope.
5 Likes
You like it, I do not.
Unless they fix things it will never replace IPv4.
Also, because of NAT, it wasn’t needed anymore. Still isn’t.
We never agree Marco, unless they fix the problems I mentioned.