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

From: Harlan Stenn <[email-masked]>
Date: Sun, 17 Jul 2011 13:04:06 -0700

Mode 6 and mode 7 *should* have been included in the NTPv4 spec.  There
is effort underway to get them back.

I have no problem with mode 7 - it is a vendor-specific way to interact
with an NTP daemon.  Granted, I haven't heard of anybody else ever using
it.

Mode 7 has traditionaly been a binary protocol, while Mode 6 has been an
ASCII protocol.  There is no *requirement* that mode 7 use a binary
protocol.

Mode 6 stuff SHOULD be documented and specified by the RFC.  It MAY be
OK to carve out some space in this specification for vendor-specific
usage.

H
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Dave Hart <[email-masked]>
Date: Sun, 17 Jul 2011 23:18:50 +0000

Harlan asked me to post this message to ntpwg@ as well.

Cheers,
Dave Hart

---------- Forwarded message ----------
From: Dave Hart <[email-masked]>
Date: Sun, Jul 17, 2011 at 06:35
Subject: disabling or removing mode 7 (ntpdc) support from ntpd
To: [email-masked], [email-masked]

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

---

From: todd glassey <[email-masked]>
Date: Mon, 18 Jul 2011 09:06:48 -0700

On 7/17/2011 4:18 PM, Dave Hart wrote:
> From: Dave Hart<[email-masked]>
No... It needs to stay for compatibility unless the parties who are 
shipping the code are planning on EOLing NTPDC
> marshalling and unmarshalling code in both ntpd and ntpdc.
This is because of a sloppy build world.
> Moreover,
> wholly redundant with ntpq.
Its not redundant but rather a binary interface. As you note there is a 
text interface with NTPQ but that is text base.
> That is, I believe as of ntpd 4.2.7p191,
> requests issued by ntpq.
Yes this is true - but so what? NTPDATE and SNTP exist pretty well 
together.
>   Please file bugs or otherwise alert us if
> you find otherwise.
>
> and ntpdc.
I think that the binary format is useful however.
>   Typically new capability can be added to ntpq without any

-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.