[ntp:questions] NTP over redundant peer links, undetected loops

Danny Mayer mayer at ntp.org
Sun Feb 15 18:23:16 UTC 2009

Dave Hart wrote:
> On Feb 15, 4:13 pm, ma... at ntp.org (Danny Mayer) wrote:
>> Dave Hart wrote:
>>> On Feb 13, 2:50 am, ma... at ntp.org (Danny Mayer) wrote:
>>>> I've had only my list of things to do to use only one refid per system
>>>> rather than based on the IP based being used.
>>> This certainly seems like a winning idea in terms of loop detection.
>>> If you do something like this, it would be nice if without extra
>>> configuration RFC1918 addresses would tend to not be used as refids
>>> (like unless the only unicast IPv4 address available is RFC1918.
>> I fail to see what RFC1918 addresses have to do with it. There's always
>> likely to be a mixture of public/private addresses in an ntp
>> configuration and I see no point in preferring one over the other.
> RFC1918 addresses are of course not globally unique, so are
> particularly ill-suited to a reference ID used for loop detection.
>> In
>> addition this ignores the IPv6 addresses and it is intended to tackle
>> that issue as well. It would be better if these were just a generated
>> 32-bit random number created at startup which is kept for the lifetime
>> of the server.
> Why play roulette if you have a globally unique IPv4 address to use as
> a refid?  Since IPv6 addresses are hashed down to 32 bits if used as a
> refid, again, IPv4 global addresses if available are better unique
> identifiers.

Because I want to get away from the notion that these are meant to be IP
addresses. In addition in an IPv6-only environment that wouldn't work
either. Why create work when it's unnecessary just to find a valid IP
address? In addition with anycast addresses are not globally unique. The
chances that you will create a non-unique random number within a network
is extremely low.


> Cheers,
> Dave hart

More information about the questions mailing list