[ntp:hackers] disabling or removing mode 7 (ntpdc) support from ntpd

Dave Hart hart at ntp.org
Sun Jul 17 06:35:06 UTC 2011


I would like to remove support for ntpdc's mode 7 management from ntpd
in ntp-dev soon.

What is wrong with ntpdc's mode 7 on-wire protocol?  It's complex,
fragile, and requires a large amount of tedious, error-prone
marshalling and unmarshalling code in both ntpd and ntpdc.  Moreover,
with the release in the next day or so of 4.2.7p191, I claim it is
wholly redundant with ntpq.  That is, I believe as of ntpd 4.2.7p191,
everything that can be done via ntpdc and its mode 7 management
traffic can now be accomplished with the simpler and safer mode 6
requests issued by ntpq.  Please file bugs or otherwise alert us if
you find otherwise.

(As an aside, in 4.2.6 and earlier, mode 7 management packets are
issued by ntpd's intres DNS code to spin up server associations after
resolving an IP address, via 127.0.0.1:123.  That means in 4.2.6,
simply ripping out support for mode 7 would also rip out support for
specifying servers by name rather than numeric IP address.  Since
early in the 4.2.7 cycle, the new intres code in ntpd does not rely on
mode 7, incidentally also enabling IPv6-only operation in theory.)

Why is ntpq's mode 6 protocol preferable?  It is largely text-based,
where mode 7 uses binary requests and responses each requiring
lengthy, error-prone marshalling and byte-swapping code in both ntpd
and ntpdc.  Typically new capability can be added to ntpq without any
protocol work, while each addition or change to ntpdc typically
requires new binary request and response packet definitions.  Also,
thanks to the preference for ntpq, ntpdc has not been as well
maintained, though it's fared better than ntpdate.

To see for yourself the inflexibility and resultant code bloat of the
mode 7 protocol, take a look at either ntpdc/ntpdc_ops.c or
ntpd/ntp_request.c focusing on how support was added for IPv6's
128-bit addresses on top of the existing 32-bit IPv4 provisions.

Unlike the situation with ntpdate, I do not propose removing the ntpdc
code anytime soon.  It will retain utility for managing older ntpd
instances for some time to come, as with 4.2.6 and earlier, some
management capabilities were only available via ntpdc (for example,
querying network interfaces used by ntpd, or fetching the recent
client address list).  On the other hand, I'm strongly in favor of
losing the mode 7 support code in ntpd/ntp_request.c, which is
voluminous, error-prone, and redundant.

One way forward would be to simply rip out ntp_request.c and call it
done.  Some might be happier with a transition period where support
for mode 7 could be explicitly configured, such as with a hypothetical
"enable ntpdc" in ntp.conf.  I would prefer the former, but as a ntpd
maintainer my perspective is biased.  What do you think?

Cheers,
Dave Hart


More information about the hackers mailing list