[ntp:questions] Three NTP servers, one strange IP-address in 'refid'
stenn at ntp.org
Mon Apr 7 09:25:29 UTC 2014
Miroslav Lichvar writes:
> 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.
You are, of course, correct.
And I wonder if it's "early enough" in the deployment of NTP on IPv6
servers that we could do this without much risk.
Of course, if we have a spare bit somewhere that we can use to identify
the contents of the refid field this is a non-issue.
There are bigger issues with the refid and loop detection. Some of
these are discussed at:
and there are other issues as well - where exactly do we need to "draw
the line" on loop detection? On multi-homed machines it should really
not be an IP address. If it's a machine instead, what if the machine
has multiple clock sources?
I gather that different "spots" in the architecture have slightly
different needs for loop detection via refid, and it would be nice to
have a clear understanding and description of these cases.
Harlan Stenn <stenn at ntp.org>
http://networktimefoundation.org - be a member!
More information about the questions