[Ntp] Re: NTPv4 client behavior to ntpv3 reply

[Harlan Stenn <[e-mail]>]

On 7/30/2024 1:00 AM, rémy decrock wrote:
> Thank you Harlan for the answer.
> 
> The issue behind my question is that I have an equipment that uses a 
> NTPv4 client and so perform ntpv4 requests to a server that only support 
> NTPv3 "Windows..."
> The server replies to my equipment but  with a NTPv3 answer and seems to 
> be ignored.
> Before creating a bug request to the vendor, I want to be sure that this 
> behavior is illegitimate or not.

Ah, thanks for the clarification.

The part that won't matter because it's in the NTPv4 spec:

  https://datatracker.ietf.org/doc/html/rfc5905#page-88

which shows:

         /*
          * Initialize header and transmit timestamp.  Note that the
          * transmit version is copied from the receive version.  This is
          * for backward compatibility.
          */

         x.version = r->version;

https://datatracker.ietf.org/doc/html/rfc1305 (NTPv3) does it a bit 
differently:

   Version Number (NTP.VERSION): This is the current NTP version number (3).

and in the "Transmit Procedure" section:

  ...
  <$Eroman pkt.version~<<-~roman NTP.VERSION>;
  ...

(please excuse the horrible formatting instructions that are actually 
part of RFC1305).

In the reference implementation, in ntp_proto.c:receive() we see:

	...
         /*
          * Version check must be after the query packets, since they
          * intentionally use an early version.
          */
         if (hisversion == NTP_VERSION) {
                 sys_newversion++;               /* new version */
         } else if (   !(restrict_mask & RES_VERSION)
                    && hisversion >= NTP_OLDVERSION) {
                 sys_oldversion++;               /* previous version */
         } else {
                 DPRINTF(2, ("receive: drop: RES_VERSION\n"));
                 sys_badlength++;
                 return;                         /* old version */
         }

and NTP_OLDVERSION is '1', so as long as you don't have 'restrict 
version' in your ntp.conf file you should be fine.

H

> Le 30 juil. 2024 à 02:09, Harlan Stenn <stenn=[e-mail]> 
> a écrit :
>> On 7/29/2024 8:11 AM, rémy decrock wrote:
>> > Hello,
>> > 
>> > I have a question about the NTP v4-v3 compatiblity.
>> > According to the RFC https://datatracker.ietf.org/doc/rfc5905/,  <https://datatracker.ietf.org/doc/rfc5905/,>  v3 and
>> > v4 are compatible.
>> > By  compatible, I understand that if a client perform an NTPv3 request 
>> > to a  NTPv4 server, this one is able to answer in an understandable way 
>> > to the client.
>> > But what if a NTPv4 client receives an NTPv3 reply to his NTPv4 requests?
>>
>> "It depends."  I say this because the reference implementation replies
>> with the packet format it knows about, using the version field from the
>> request.  So you will not see the case you describe from the reference
>> implementation.  We took great pains to make sure clients and servers
>> running different NTP versions would interoperate successfully.
>>
>> If the V3 server was written by somebody else, it will behave the way it
>> will behave.
>>
>> The first/early release of NTPv4 happened before February 1998.
>>
>> The last release of NTPv3 was in November of 1998.
>>
>> There were no interoperability complaints around the switch from v3 to v4.
>>
>> NTPv3 has not been supported for over 25 years' time.  I gotta wonder
>> how many v3 servers are actually still running out there.
>>
>> > Thanks.
>> > 
>> > _______________________________________________
>> > ntp mailing list -- [e-mail]  <mailto:[e-mail]>
>> > To unsubscribe send an email to [e-mail]  <mailto:[e-mail]>
>> -- 
>> Harlan Stenn <[e-mail]>
>> The NTP Project is part of
>> https://www.nwtime.org  <https://www.nwtime.org>/ - be a member!
>>
>> _______________________________________________
>> ntp mailing list [e-mail]  <mailto:[e-mail]>
>> To unsubscribe send an email [e-mail]  <mailto:[e-mail]>

-- 
Harlan Stenn <[e-mail]>
The NTP Project is part of
https://www.nwtime.org/ - be a member!