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

Rob nomail at example.com
Thu Apr 3 20:31:17 UTC 2014


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.

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.



More information about the questions mailing list