[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 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)

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

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list