Restrict/unrestrict without IP version behave inconsistently
This bug has probably been around for a long time, but the change in the default restrictions in 1.1.9 broke ntpq, and adjusting the restrictions to unbreak it uncovered the bug.
Typical examples for restrict/unrestrict (when intended to be IP-version agnostic) do something like this:
restrict restrict -6 unrestrict unrestrict -6
The implication is that the omission of the -6 implies -4, but that doesn't seem to be the case in practice. In trying to do something of that form, I saw a case where the same restrict/unrestrict statements to the same ntpsec version on the same OS version on two different machines behaved differently. I determined that it could be fixed by changing the above to:
restrict -4 restrict -6 unrestrict -4 unrestrict -6
The most likely explanation is that the "unversioned" statements are opportunistically applying to IPv4 or IPv6, based on some unknown criterion. The failing case involved both restrict and unrestrict statements, and I don't know for certain that it applies to both, but it seems likely that they share the relevant code. I'm not sure how reproducible it is, but it might be determinable by inspection.
The most reasonable interpretation of the unversioned statements is that they should apply consistently to both IPv4 and IPv6 (if applicable), simplifying the common case where restrictions aren't meant to be IP-version-dependent. That could break some existing installations, though, in cases where the behavior was as expected due to luck.
Note that testing this is complicated by another long-standing bug where ntpq doesn't honor the -4 and -6 options. To be sure of which IP version one is using, one needs to use numeric IP addresses of the intended type.