I’d be pretty hesitant to block at a threshold as low as 75 reqs/sec. That’s well within the realm of what can be generated as legitimate traffic from behind a single CGNAT IP. Even without CGNAT, a single business, school etc. could generate that much traffic simply by having a bunch of clients attempt to synchronise simultaneously.
As mentioned above, we’re talking about a fairly small amount of traffic. If 75 reqs/sec is enough to cause problems for the OP, then perhaps their server shouldn’t be in the pool at all.
Since NTP is UDP traffic, an excessive number of connections may overwhelm less beefy routers, since the protocol requires more resources to track its connections. Whether it’s raw traffic flooding the pipes or numerous connections choking the hardware resources, it’s still a DoS attack.
Pool server operators should generally be disabling connection tracking for NTP anyway. It’s a connection-less protocol, and regular pool load is diverse enough to cause resource problems on a wide variety of routers if you attempt to track every request.
Assuming conntrack is disabled, then even a really shitty router can cope with a very high level of NTP traffic without any problems at all.
This depends on router’s role, actually. There are many situations where turning conntrack off globally is desirable, particularly for transit routers. It wasn’t what I was recommending here, however - my comments were relating to NTP specifically. It is generally sensible to disable it for NTP traffic to / from pool servers (i.e. traffic to / from UDP port 123 on the pool server IP), due to the extreme diversity of the load. This is especially applicable to servers which are part of the global zone.
That is entirely incorrect. Granular control over connection tracking has nothing to do with what resources a router may have available (i.e. “beefiness”) - rather, the key factor here is whether the router’s management software exposes that capability. Here is an example of such a low-end router.
Almost every router using a Linux kernel (which realitically means most lower end routers you are likely to encounter) has the capability internally, as they use the kernel’s routing stack & firewall. Fewer of them expose it via the standard management interface, although in many cases if you can get shell access to such devices, it’s often possible to add specific no-conntrack rules to the firewall directly.
IPv6 addresses can be automatically generated from MAC addresses, so these could be devices that happen to run the same OS and use a common NIC vendor. If there are enough of them in one place, eventually consecutive MAC addresses would cluster together. This would also explain why they have similar behavior, if that’s what’s bringing them to your attention. If they’re assigned IPv6 by DHCP then the DHCP server might be generating the IPv6 from the client MAC, so correlations could appear due to a popular DHCP server implementation.
Some vendors don’t even bother with unique MAC addresses. In my junk drawer I have a collection of USB wireless NICs from Amazon that all have the same MAC address. They work as long as no more than one of that model NIC is connected to any single access point. Can’t override the MAC from the driver because the firmware doesn’t allow it.
This phenomenon also happens with IoT devices and hobbyist DIY boards where the NIC’s MAC is part of the SoC firmware. If nobody goes out of their way to assign a non-default MAC to each device, then they’ll all ship with the same MAC, and they’ll end up with similar IPv6 addresses. At least those can be fixed by a software update.
