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: http://support.ntp.org/bin/view/Dev/UpdatingTheRefidFormat 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 <[email protected]> http://networktimefoundation.org - be a member! _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
