Enable IPv6 on all zones if available #176
Conversation
|
My reasoning for leaving everything on 2. is that if a zone only has one IPv6 NTP server, it will get that server on zone.pool, and 1.zone.pool, and then it will stop. If people have hardcoded 2 into their ipv6 client, that host will be on zone.pool, 1.zone.pool and 2.zone.pool. It's an edge case, I realise, but better to be safe than sorry 8) |
|
Are there any problems with this PR? |
|
Hi Rob, not any problems as such. I just haven’t had time to think about it and don’t have time in the next weeks / months to help make sure it’s working appropriately. I’ve been testing and finishing some other changes and cleanups on the beta site.
I’d like to first do some of the planned changes to “backfill” the underserved zones with servers that can take extra queries. Otherwise I’m worried it’ll just make some of the current IPv4 problems also come up on the IPv6 zones.
|
|
Well, how about we just turn this on for the AU zone? I can update the pull request so that you whitelist zones, and you can add them as you feel comfortable with it. That lets me do my IPv6 presentation AND lets you stage the rollout! |
|
|
||
| # Historically, only '2' has had ipv6 records, so we ALSO put all | ||
| # of the records there, for anyone who is relying on 2 having a | ||
| # large number of entries (Who would do such a crazy thing?) |
There was a problem hiding this comment.
there's one of the "vendor zones" that needs this. The bits somewhere to specify the zone is an "sntp" or "ntp" zone is supposed to do something appropriate with this.
For regular ntp zones (the defaults?) we shouldn't duplicate between two numbered zones.
|
|
||
| # Smear the rest of the IPv6 records over the remaining zones, |
There was a problem hiding this comment.
I'd rather have IPv4 and IPv6 work the same; except .. again, we need a toggle to not swap the behavior for the "vendor zones". (Some of them might not handle IPv6 records and expect 0.x to not have them, for example, and many of them might not have contact information or even any active maintenance or support).
|
I assume you closing it means that you're giving up on IPv6? I'm really not sure why there's so much heartache here - if devices don't ask for AAAA records, they won't get IPv6 records. If they ask for AAAA records and then crash because they don't understand IPv6, I don't think that's YOUR problem - it means the devices will be crashing for many other reasons. |
|
I totally agree with @xrobau. Please do not close this PR. We need the entire pool to be IPv6-enabled. Here's one of many reasons for that: There is an increasing amount of IoT-devices, of which many behind behind Carrier Grade NAT, that do an SNTP-request on regular intervals. See https://status.ntppool.org/ for this, but remember; in reality there are much more DNS-queries that aren't logged due to DNS-caching. What this means is, that at the top of the our thousands of devices receive the same four IP-addresses from their ISP's resolver (because after one DNS-lookup the answer is cached for 150 seconds and handed out to all other clients that do the same DNS-query for Luckily an increasing amount of NTP-clients is capable of doing IPv6 (~73% of all ~850 million internet users in India, for example, most of them behind CGNAT) and ~50% of all servers in the pool are IPv6-capable too. And there are no further obstacles to move ahead and add AAAA's to all zones in the pool. This has been extensively discussed in this forum post. |
|
I only have an IPv6 connection where I live. |
I've tried to comment a few times on the forum, but all my posts are getting held up by the spam filter. I thought a better idea would be to just write the code, and THEN argue about it 8)
I should point out this is 100% untested, but hopefully the concept is sound enough to actually get into production, to get the ipv6 data bootstrapped.
You can also wrap that with an if $name == "au", if you're worried about it, as I'm the process of setting up a bunch of ipv6 stratum 1 servers in australia.