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

Rob nomail at example.com
Fri Apr 4 09:41:56 UTC 2014


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 172.2.53.81 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 "172.16.14.25".

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)

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

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



More information about the questions mailing list