[ntp:questions] Three NTP servers, one strange IP-address in 'refid'

Martin Burnicki martin.burnicki at meinberg.de
Mon Apr 7 07:28:09 UTC 2014

Rob wrote:
> Martin Burnicki <martin.burnicki at meinberg.de> wrote:
>> Rob wrote:
>>> Harlan Stenn <stenn at ntp.org> wrote:
>>>> Martin Burnicki writes:
>>>>> Harlan Stenn schrieb:
>>>>>> Sander Smeenk writes:
>>>>>>> Quoting Miroslav Lichvar (mlichvar at redhat.com):
>>>>>>>> For IPv6 addresses the refid is defined as first 4 bytes of the MD5
>>>>>>>> sum of the address. With 2001:7b8:3:32:213:136:0:252 (tt52.ripe.net)
>>>>>>>> that is 0xac023551, or in the quad-dotted notation.
>>>>>>> Miroslav, you're right. This is it. Thanks.
>>>>>>> I consider this a bug.
>>>>>> As do we all.  And we can fix it as soon as a decent solution appears.
>>>>> Maybe just print the refid as hex bytes instead of dotted quads unless
>>>>> it's interpreted as string?
>>>> Printing 32 bits of information in dotted-quad format takes 15
>>>> characters.
>>>> Printing 128 bits of information in base64 takes 22 characters.
>> I didn't mean to break the protocol by extending a 32 bit field to 128 bit.
>> I just meant to print the 32 bit refid field from the NTP packets in hex
>> instead of dotted quads, unless they are interpreted as ASCII
>> characters, e.g. "AC100E19" instead of "".
> I do understand that is what you meant, but then Harlan started about
> printing 128 bits of information in base64.  There are no 128 bits
> available, so finding out how to print them is not currently required.
> (although in general there is an issue with printing IPv6 addresses in
> tabular output, which also affects ntpq and ntpdc)

Oops, the previous part of my reply should have been a reply to Harlan's 
posting. Sorry for the confusion.

>> This would prevent many people from interpreting this as an IPv4
>> address. ;-)
>> Of course a better solution would be to be able to distinguish it the 32
>> bit number is a full IPv4 address, or only a 4 byte hash of an IPv6
>> address, and display an IPv4 address as dotted quad, and a hash as hex
>> number. I don't know if a tool like ntpq can determine what the refid
>> actually represents.
> Not from the value alone.  There apparently is a hack (described in the
> standard) that whenever the server is stratum-0 the refid is printed
> in ASCII and when it is not, it is printed as a dotted quad.
> But it has no way of knowing if the dotted quad is an IPv4 address or
> the hash of an IPv6 address.

Yes, that's also how I thought it's actually working.

>>> The problem is not the printing!
>>> Before 128 bits of information can be printed at all, the protocol
>>> has to be modified to transfer the bits in the datagrams.
>>> The use of a 32-bit field for the refid is as hardwired in the protocol
>>> as 32-bit addresses are in IPv4.
>>> It is not realistic to change this.  What could be changed is the use
>>> of the 32 bits when IPv6 is in use (as I proposed), and the printing
>>> of the 32 bits in that case.
>> Sorry, I don't remember your proposal. Do you have a pointer to it?
> I made it elsewhere in this thread.
> When the NTP server puts an IPv6 hash in the refid field, it could set
> the upper 4 bits to 1.  (so the hex value starts with F)
> A valid IPv4 address never has that, so ntpq could print it in hex in
> this case, and as a dotted quad in other cases.
> This also guarantees a hashed IPv6 can never collide with a valid IPv4
> refid.  But at the same time, it shrinks the space of IPv6 hashes,
> increasing the chance of a hash collision between two IPv6 addresses.

In my opinion this sounds reasonable. The danger of collision might be 
slightly higher (less with IPv4, a little bit more with another IPv6 
hash), but for users it would avoid confusing IPv4 addresses with IPv6 

Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont

More information about the questions mailing list