thoughts on fake IP addresses and clock specification

Hal Murray hmurray at megapathdsl.net
Tue Dec 1 04:58:28 UTC 2015


>> I am not at all a fan of using weird unroutable IPv4 addresses to specify
...

> *Emphatically* agreed.  It has been on my mind for a while that this
> misfeature (and the associated horrible mess around refids) must die -
> namespace cleanup was in the original tech plan I wrote back around January.
>  But as a vague blue-sky sort of thing, because it's going to take a major
> (and incompatible) rev of the NTP protocol to get there. 

You aren't making sense.  Those fake addresses have nothing to do with the on 
wire protocol.

Or perhaps I'm not up to speed on what you mean by "protocol".  There are 3 
different parts to the protocol.  There is the timekeeping stuff, modes 1 
through 5, I think.  There is mode 6 that ntpq uses.  There was mode 7 that 
ntpdc used to use, but we nuked that.

I think there is documentation for mode 6 in the RFCs, but it is already way 
out of date and nobody is going to notice if we make more adjustments.  
(especially if their old ntpq keeps working)

The only serious problem I know of in the timekeeping protocol is that there 
is a 32 bit slot to identify the primary upstream server (sys peer).

For stratum 1 clocks, that's re-purposed as a text string.  That's a hack, 
but clean.

For IPv4, the IP Address fits into that slot and is unambiguous and clean, 
and often used for tracing bogus data.

For IPv6, the address doesn't fit.  A hash of the IPv6 address is used, but 
there is no way to distinguish a hashed IPv6 address from a IPv4 address.  
Harlan had a scheme for stealing a few top bits to mark IPv6 addresses.  I 
don't know if he implemented it and/or if we have that code.


-- 
These are my opinions.  I hate spam.





More information about the devel mailing list