Skip to content

Enable IPv6 on all zones if available - #176

Closed
xrobau wants to merge 2 commits into
abh:masterfrom
xrobau:master
Closed

Enable IPv6 on all zones if available#176
xrobau wants to merge 2 commits into
abh:masterfrom
xrobau:master

Conversation

@xrobau

@xrobau xrobau commented Sep 8, 2019

Copy link
Copy Markdown

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.

@xrobau

xrobau commented Sep 9, 2019

Copy link
Copy Markdown
Author

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)

@xrobau

xrobau commented Sep 15, 2019

Copy link
Copy Markdown
Author

Are there any problems with this PR?

@abh

abh commented Sep 15, 2019 via email

Copy link
Copy Markdown
Owner

@xrobau

xrobau commented Sep 16, 2019

Copy link
Copy Markdown
Author

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!

Comment thread lib/NP/Model/DnsRoot.pm

# 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?)

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread lib/NP/Model/DnsRoot.pm
push @{$data->{$pgeodns_group}->{aaaa}}, $_ for @$entries;
}

# Smear the rest of the IPv6 records over the remaining zones,

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

@abh
abh deleted the branch abh:master August 26, 2021 01:15
@abh abh closed this Aug 26, 2021
@xrobau

xrobau commented Aug 26, 2021

Copy link
Copy Markdown
Author

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.

@mdavids

mdavids commented Oct 14, 2021

Copy link
Copy Markdown

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 pool.ntp.org). Then they are trying to contact these four IPv4 addresses at roughly the same moment from behind one single (or perhaps only a few) CGNAT IPv4-addresses. This will immediately result in rate limiting kicking in for many of those requests. With IPv6 this will not happen, because all clients will come from a unique source IP-address.

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.

@deavmi

deavmi commented Feb 11, 2024

Copy link
Copy Markdown

I only have an IPv6 connection where I live.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants