thoughts on fake IP addresses and clock specification

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 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)

Ah, that's good to know.

> 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.

This is part of what Mark and I have been looking at and going "Ewwww!".

In a fully IPV6 world that sys peer slot is going to need to be 64
bits rather than 32.  Are there any principled reasons to believe the
address collisions cannot be a problem?  If there aren't, that in itself
will force a protocol break, won't it?

The parts of the code that handle the peer ID slot do nasty type punning;
they're easy to misread and easy to damage.  I don't think that hack is
"clean" at all, at least not as implemented.

I was under the impression that ntpd is internally set up so that clock
samples come in as though they were packets from peers, with the fake
IPv4 addresses for their type and unit ID in the refid field. If so,
then the fake addresses really are part of the wire protocol. Am
I in error about this?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>