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
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.