Subject: Re: [Ntp] Questions on https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02

From: Brian Haberman <[email-masked]>
Date: Fri, 1 Sep 2017 08:58:56 -0400

Hi Ulrich,
     Thanks for the review and comments!

On 8/31/17 7:39 AM, Ulrich Windl wrote:
> Hello!
> 
> I just read https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02 to verify my older implementation of NTP control messages.
> I found some things that are strange! For example:
> 
> (Page 4): "The original development of the NTP daemon included a remote facility (ntpdc) for monitoring and configuration. This facility used mode 7 commands to communicate with the NTP daemon. This document illustrates the mode 7 packet format only.": I thought the document describes mode _6_ packets!?
> 

Someone asked that the mode 7 packet format be added to this document
for completeness. The section you reference is strictly for mode 7. The
previous section on that page (Section 1.1) discusses the mode 6 commands.

> Similar "The mode 7 message format is shown in Figure 3.: Why describe the packet format then?
> 

See above.

> While the draft talks about sequence and version numbers in the mode 7 packet, it fails to specify it for mode 6 packets:
> "Version Number (VN): This is a three-bit integer indicating a minimum NTP version number. NTP servers do not respond to control messages with an unrecognized version number. Requests may intentionally use a lower version number to enable interoperability with earlier versions of NTP. Responses carry the same version as the corresponding request.": What is the version number the draft specifies? Obviously the first NTP version to support a mode 6 or 7 packet is version 2.

The minimum version would be 2. Given that there doesn't seem to be any
interest in adding new mode 6 commands, I didn't see a need to specify a
version number for this document. If it would help, I could indicate
that this document specifies mode 6 commands for version 4 (and earlier).

> As the definition of the Clock (Radio) Status word is quite different between NTPv3 and NTPv4 (just as the System Event Code is) I wonder how a conforming implementation will handle the VN transmitted in the request packet: Will it respond with the correct packet regarding NV, will it flag obsolete requests as an error (the current implementation does not), or will it always return the current format? ("will" obviously should either "SHOULD" or "MUST" in a specification)
> 

That is a good point for the WG to discuss. The goal of this document
was to ensure a stable reference for mode 6 commands that were
originally described in RFC 1305 (since obsoleted). My view is that it
should return the format that matches the version number, but I do not
maintain an NTP implementation, so this should be discussed.

> On page 6: "Each request uses a different sequence number.": Is this a recommendation (SHOULD) or a requirement (MUST)? Obviously it should help against spurious packets being received (or for multiple outstanding requests when the order of packets received may vary).

I think this needs to be a MUST statement. That particular text was
lifted directly out of 1305 before the introduction of 2119 keywords.

> 
> An unanswered issue is how to find out what version the remote party supports, i.e. how to find out whether the remote party is NTPv3 or NTPv4 (for example). Reading variable "version" with a low VN to guess the version will fail on Solaris for example, where the daemon does not return a version string...

To me, that is adding a new feature/command to mode 6 to perform version
discovery. Is that necessary?

Regards,
Brian

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Brian Haberman <[email-masked]>
Date: Fri, 1 Sep 2017 08:58:56 -0400

Hi Ulrich,

See above.

Regards,
Brian

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 01 Sep 2017 15:56:15 +0200

>>> Brian Haberman <[email-masked]> schrieb am 01.09.2017 um 14:58 in
Nachricht <[email-masked]>:
>> I just read https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-02 to 
> verify my older implementation of NTP control messages.
>> (Page 4): "The original development of the NTP daemon included a remote 
> facility (ntpdc) for monitoring and configuration. This facility used mode 7 
> commands to communicate with the NTP daemon. This document illustrates the 
> mode 7 packet format only.": I thought the document describes mode _6_ 
> packets!?
>> 
> 

Yes, maybe move the description for that packet to some appendix.

>> Similar "The mode 7 message format is shown in Figure 3.: Why describe the 

See above also ;-).

> 
>> While the draft talks about sequence and version numbers in the mode 7 
> packet, it fails to specify it for mode 6 packets:
>> "Version Number (VN): This is a three-bit integer indicating a minimum NTP 
> version number. NTP servers do not respond to control messages with an 
> unrecognized version number. Requests may intentionally use a lower version 
> number to enable interoperability with earlier versions of NTP. Responses 
> carry the same version as the corresponding request.": What is the version 
> number the draft specifies? Obviously the first NTP version to support a mode 
> 6 or 7 packet is version 2.
> 

As I indicated, the problem is not only the assigned command numbers (opcode), but also the interpretation of some status words: Maybe try to add a section on how to find out what status format the server being queried does send back. Maybe then you'll see my problem... ;-)

> 
>> As the definition of the Clock (Radio) Status word is quite different 
> between NTPv3 and NTPv4 (just as the System Event Code is) I wonder how a 
> conforming implementation will handle the VN transmitted in the request 
> packet: Will it respond with the correct packet regarding NV, will it flag 
> obsolete requests as an error (the current implementation does not), or will 
> it always return the current format? ("will" obviously should either "SHOULD" 
> or "MUST" in a specification)
>> 
> 

Also the opcodes specified are more than those of RFC1305.

> 
>> On page 6: "Each request uses a different sequence number.": Is this a 
> recommendation (SHOULD) or a requirement (MUST)? Obviously it should help 
> against spurious packets being received (or for multiple outstanding requests 
> when the order of packets received may vary).
> 
>> An unanswered issue is how to find out what version the remote party 
> supports, i.e. how to find out whether the remote party is NTPv3 or NTPv4 
> (for example). Reading variable "version" with a low VN to guess the version 
> will fail on Solaris for example, where the daemon does not return a version 
> string...
> 

I think yes, because the alternatives are ugly.
Here are snipplets from some Perl code I wrote years ago:

        my $NTPv4 = $vars->has_variable('frequency');   # NTPv4 or newer?
 
[...]
    # guess NTP version
    $control = NTP_Control->new($ht);
    if (my $vars = $control->read_vars(0, 'version')) {
        my $ver = $vars->variable('version') // '';

        if ($ver =~ /^x?ntp[^\d]*(\d)(?:\.\d)/) {
            $ht->ntp_version($1);
            ::Log(0, 'D', $logger,
                  "NTP version found to be", $ht->ntp_version(), "($ver)")
                if ($debug > 2);
        } else {
            ::Log(0, 'E', $logger, "Failed to parse version: $ver");
        }
    } else {
        ::Log(0, 'E', $logger,
              'Failed to query NTP version for', $ht->host_sock_string());
        goto out;                       # no response, probably no NTP
    }

And not to talk about the mess with variable names:

        if (!$NTPv4) {
            $vars->set_variable('frequency', $vars->variable('freq') / 1000);
            $vars->set_variable('offset', $vars->variable('phase'));
            $vars->set_variable('noise', $vars->variable('error'));
            $vars->set_variable('jitter', 0);
            $vars->set_variable('stability', '0');
        } else {            # ntpd 4.2.6p2 "introduces" "new" variables
            $vars->copy_variable('rootdispersion', 'rootdisp');
            $vars->copy_variable('noise', 'clk_jitter');
            $vars->copy_variable('jitter', 'sys_jitter');
            $vars->copy_variable('stability', 'clk_wander');
            $vars->copy_variable('poll', 'tc');
            # ntpd 4.2.8 also has new variables
            # "clk_jitter" (CS_ERROR),

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 01 Sep 2017 15:56:15 +0200

See above also ;-).

 
[...]
    # guess NTP version

        if (!$NTPv4) {

Regards,
Ulrich