[ntp:questions] Re: refid on client differs from refid on local server

David L. Mills mills at udel.edu
Sun Dec 18 21:32:12 UTC 2005


You are concerned about the reference ID display in ntpq when a remote 
client of a local server has synchronized to an IPv6 server. Whether the 
hash of the client destination address matches the reference ID in the 
packet, thus confirming a loop, is not the issue. The issue is what to 
tell the ntpq monitor program. It was the intent to send raw data to 
ntpq that could be displayed directly, although ntpq usually cooks it. 
So, the ntpd program has the choice on how to format the field. But, 
ntpd does not know whether the reference ID field is an IPv4 address or 
hash of an IPv6 address.

There are a couple of simple things that could be done. If a loop is 
detected, ntpd knows the address family. If not, try the autocorrelation 
function, which should be flat for a good hash and probably peaky for a 
legitimate IPv4 address. In today's Internet with dense 32-bit address 
space, that might have a poor hit rate. What is needed is a little 
steganography, so plant bits in the hash that can be detected by the 
local server.

Here's a way this could work. The client knows when a loop can occur, so 
in that case operate as prescribed. If a loop does not occur and the 
client is synchronized to another IPv6 source, the hash won't match. In 
that case hijack the reference ID field to a defined but unlikely value 
that the local server can recognize. An all-zero value comes to mind. 
What that means to the local server is that the client is synchronized 
to another IPv6 source, so the local server can send a fake reference ID 
  of "IPv6" to the ntpq program.

I have no problem with this and it does conform to the design intent. I 
wonder if this is making to fine a point on the display interpretation.


Danny Mayer wrote:
> David L. Mills wrote:
>>The ntpq already does display one of the "other" types, in particular if
>>a reference clock or kiss code is involved. This was a recent change to
>>avoid the misleading IP address for reference clocks operated at an
>>elevated stratum. Note that in orphan mode the refid displayed is the
>>loopback address, but this is entirely legit.
> Dave,
> That part is fine. I just want to disabuse people from thinking that's
> an IP address when it uses a value in there rather than a string.
> Danny
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions

More information about the questions mailing list