[ntp:questions] Three NTP servers, one strange IP-address in 'refid'
martin.burnicki at meinberg.de
Mon Apr 7 07:28:09 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 188.8.131.52 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
>>>> 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
More information about the questions