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.
6 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.
4 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.
9 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. 
3 Likes