[ntp:questions] Conflicting information on packet field types

Miroslav Lichvar mlichvar at redhat.com
Fri Nov 2 08:50:19 UTC 2018


On Tue, Oct 30, 2018 at 10:31:58PM -0500, Jason Rabel wrote:
> However, RFC 4330 goes a little more in-depth saying, "This is a
> 32-bit signed fixed-point number indicating the total roundtrip delay
> to the primary reference source, in seconds with the fraction point
> between bits 15 and 16.  Note that this variable can take on both
> positive and negative values, depending on the relative time and
> frequency offsets.

Interesting. RFC 1305 has signed root delay and dispersion too. I
never noticed that. I thought the only differences in the format of
NTPv3 and NTPv4 packets was the IPv6 reference ID and extension
fields.

> I know this is all a bunch of 'what if' scenarios that probably will
> never happen... Especially with the packet NTP sends out apparently is
> unsigned for root delay. But again my thoughts are about other time
> programs out there. I'm going to take a wild guess and say that (under
> normal circumstances) if NTP (or any time program) is calculating a
> negative delay (and likely a huge time offset), it's probably also
> considering itself unsynced and won't send out time to any clients
> that request it until things normalize.

The two NTP implementations I'm most familiar with both work with an
absolute value of the delay. So, even if the frequency error is so
large that the measured delay is negative, the root delay should
accumulate a positive value.

A potential issue is with values in the 32768-65536 range, which could
be used by a server that lost synchronization long time ago and old
clients following RFC 1305/4330 would misinterpret it as a negative
value.

-- 
Miroslav Lichvar


More information about the questions mailing list