[ntp:hackers] NTP Development Snapshot ntp-4.2.8p3-RC1 Released

Harlan Stenn stenn at ntp.org
Sat May 23 19:44:59 UTC 2015


Majdi,

This is a long-known problem.  NTP uses the interface IP for the refid,
and that means any machine with multiple interfaces will generate
multiple refids, rendering the loop detection stuff less effective.

This topic is something we're discussing on
http://support.ntp.org/bin/view/Dev/UpdatingTheRefidFormat .

H
--
"Majdi S. Abbas" writes:
> On Sat, May 23, 2015 at 06:40:31AM +0000, Harlan Stenn wrote:
> > Good catch, Nathan.  I should have caught that, too.
> > 
> > I'm game to implement the fix identified by Dan Mahoney in comment #9 of
> > bug 278, and http://support.ntp.org/bin/view/Dev/UpdatingTheRefidFormat
> > in which IPv6 refids would be 255.x.y.z, using a 24-bit hash of the IPv6
> > address instead of the current 32-bit hash.  This should avoid
> > collisions just fine, I think.
> > 
> > Is this something acceptable to do for 4.2.8pX or should it go in 4.4.0?
> 
> Harlan,
> 
> 	I think it's acceptable now but I'm not sure it goes far enough.
> If we're going to change the resulting refIDs, I'd suggest something
> like:
> 
> 	For dual stack hosts that return both an A and AAAA (even
> if the querier isn't dual stack capable itself, it might be worth
> querying both record types just to see if the server they are talking 
> to is):
> 
> 	255.XOR of (IPv4 address hash and IPv6 address hash.)
> 
> 	Otherwise, v4 address alone, or 255.v6 address hash alone.
> 
> 	I have a mixed environment where many NTP servers are dual
> stack, but a few are behind networks that are still v4 only.  The
> result is that ntpd fails to reliably detect loops since there are
> two possible refids for the same server.
> 
> 	If single protocol v4 hosts used the same refIDs to refer
> to a server as a dual stack host does, then the loop detection
> algorithm will work a lot better than it current does in mixed
> environments.  
> 
> 	--msa
> 


More information about the hackers mailing list