Is the reason now known?
pool2 has it enabled and I am not aware of any issues.
My understanding is that there is the perceived issue that some legacy vendor zones have intentionally been set up to be IPv4 only, and that shall be maintained. As the vendor zones are currently essentially aliases for the generic pool names only, the latter cannot be changed without affecting the former.
Thus, enhancements to the process as to how vendor zones are being managed are considered needed, not only for the IPv6 topic.
That is a slightly bigger undertaking, which keeps getting pushed out as other items are considered more important, or are more pressing.
E.g., right now the currently ongoing migration of much of the Pool backend away from Equinix Metal needs to be completed before that service will be sunset on June 30, 2026, as any remaining resources being left provisioned after that date will be permanently deleted.
In any case, Ask can only spend a portion of his time on the Pool, and much of that is taken up by maintenance activities such as the migration, leaving only a small portion for other major development work
Does that also apply to 2.vendor.pool.ntp.org ? 
I think the point is that the other zones shall not change their properties. Assuming that if IPv4-only was/is desired, those are what got provisioned into devices, and thus they should not change retroactively.
That’s nonsense. No IPv6 addresses will be returned to DNS queries of type A. There is no technical reason why the pool should not fully support IPv6.
1 Like
Why is the pool run by only one person?
How dare you question the most sacred superstition about the pool?
You have an odd way of using unnecessarily ambiguous language to simple questions. Sounds like trolling.
As far as I can see, most of the vendors I know about (mostly various Linux distributions) follow the usual pattern where only 2.xxx.pool.ntp.org is IPv6-enabled. There might be vendor zones which the vendor has requested to be IPv4-only, but I’m not aware of any. On the other hand, there is at least one vendor who has explicitly requested to have IPv6 addresses in their vendor zone, but those haven’t been set up.
So, maybe in short – it varies.
As far as I’m concerned, I’d just notify the vendors that “Starting from $date all your vendor zones will have IPv6 addresses as well, deal with it.” If that’s a problem for someone, they’ll likely respond somehow.
1 Like
Really? Not dual-stack? As in the e.g. Fritzbox you can go Ipv6 native and turn off IPv4, when you do that not many sites work 
Have a look, it’s terrible how low IPv6 sites are:
Also funny, many of the IPv6 promoting sites don’t work anymore or are outdated.
People do not like IPv6 and the ones that use it are clueless about the internet and just use s**t-media
That would be a good idea. That means it is known which vendors have
worries, so they can be addressed.
I have some machines that are IPv6 only, combined with NAT64/DNS64 to
reach the legacy sites if that is really needed. Certain virtual
machines don’t have IPv4 connectivity at all and no NAT64, works fine
for my use cases. I then just disable the IPv4 only NTP pool in this cases.
The 0., 1., 3., and unnumbered zones are IPv4-only, so anyone wanting IPv4-only is supposed to use those. And the point, as far as I have understood it, is that they remain IPv4-only, for those vendors who requested there to be IPv4-only zones, and who now have configured devices based on that.
(I am just trying to explain what I have understood to be the blocking point to enabling more, or additional zones with IPv6. I personally do not see a reason not to, with many approaches how to manage the transition having been proposed and discussed in the past.)
As said, the vendor zones are just aliases to the generic zones. Not in the DNS sense (e.g., CNAME record), but internal to the logic that generates the zone data. It creates a pseudo “alias” record in the GeoDNS zone file, that the GeoDNS server will then interpret accordingly. I.e., serve the data of the zone referenced by the “alias” record.
And whether the numbered zones are generated seems to hinge on whether the vendor zone is for SNTP clients, for NTP clients, or both (rather, whether the client is designed to use a single name only, or multiple names). I.e., it looks as if it were just a flag that needs to be set somewhere to enable numbered zones, including the dual-stack 2. one.
That are nonsense arguments. ISPs can provide static IPv6 nets like they
can do for IPv4, I have such a contract and get a /48.
But they don’t for normal users.
Typical they charge 150 euro a month to have static!!!
That are arguments against this ISP, but not against IPv6. They can do
the same for IPv4 and there is a real reason to do so, as some need to
rent address ranges.
All others rip you off big time!!! They do NOT offer static, not IPv4 or IPv6 unless you pay 150 EURO a month.
Belgium is a great country where ISP’s are allowed to f*ck you…legaly!!!
At all, nothing wrong with IPv6 in this case, those are gaslighting
arguments.
You are currently doing it. This thread is about IPv6 in the NTP pools,
not the offers of Belgian ISPs and your failed try to blame IPv6 for the
issues of those ISPs.
1 Like
I concur. May I ask for the discussion to stay closer to the original topic of this thread, please. This is not the place to air general grievances.
Also, I object to being called “clueless”. And as asked by myself and others before, please do not speak on behalf of others by using phrasing such as “People do not like IPv6”. At least I, and it seems many others as well, are not covered by that statement. Please speak only for yourself.
And I even more strongly object to the use of language in some recent posts. Please stop that going forward, and please sanitize recent posts.
1 Like
Yes, you can. Of course you can.
My Fritz!Box does it (in the myfritz.net domain), just to mention one example.
I can’t do anything against bad ISPs and they can give you a bad
experience with IPv4 too. Many in Germany do not give you a public IPv4,
they don’t have enough address space. If you want to reach your servers,
you can only use IPv6.
DynDNS works fine for IPv6 too, just run the client on the server itself
and not on the router, as there is usually no NAT.
Although, this discussion thrives too far away from the original topic.
Meanwhile around 59% of the servers in the NTP pool are reachable via IPv6.
(Assuming a total of 3,796, of which 2,251 support IPv6 alongside IPv4, although this may not be entirely accurate, as some of my servers, for example - are IPv6-only.).
1 Like