On Mon, Apr 07, 2014 at 09:28:09AM +0200, Martin Burnicki wrote: > Rob wrote: > >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.
If I'm not mistaken, the main purpose of the refid value is detection of synchronization loops. To not break that, all NTP servers would have to update their refid definition at the same time. That's not doable. Fixing the tools to print the value in hex instead of dotted quads to avoid confusion seems like a better fix to me. -- Miroslav Lichvar _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions