[LEAPSECS] Leap seconds ain't broken

[Martin Burnicki]

Steve Summit wrote:
> It'd be nice to extend NTP with some kind of "provenance" field
> which could say that a certain server is delivering smeared time.

In fact ntpd also even does so. While smearing is in affect the "refid"
field sent in replies to clients is set to "254.aa.bb.cc", where
"aa.bb.cc" can be interpreted as a 24 bit number representing the
current smear offset, e.g.

int32_t tmp = ( ntohl( refid ) << 8 ) & 0xFFFFFF00UL;
smear_offs = ( (double) tmp ) / (double) 0x40000000;

See also:
https://support.ntp.org/bin/view/Dev/LeapSmearForNTPv4

However, I doubt the Google servers have this implemented.

The problem is that only direct clients of a smearing server get this
refid. Clients of those clients have no chance to determine the smear
offset.

As said earlier, the current implementation is just a hack which tries
to get the most out of it without breaking compatibility of the protocol.

> The same field could be used to make explicit the fact that
> ut1-time.colorado.edu is delivering UT1.  (The same field
> could *also* be used with a hypothetical set of NTP servers I'd
> like to deploy that would deliver several phases of shifted time
> such that, on one or another of them, every day's a leapsecond
> day, so that people could temporarily sync to it to, like,
> actually test how their systems behave in the face of leap
> seconds.)
> 
> Since RFC 5905 describes new, tagged, extended fields for the NTP
> protocol, this sort of extra information should be very easy to add.

I agree it would be good to implement this in an extension field, but
generally care should be taken not to break compatibility. I mean, how
do existing clients act if they receive a packet with unknown extension
field? Do they just ignore it, or do they just drop and ignore the whole
packet?

Eventually the protocol version should be bumped to 5 so v5 servers can
add the extension field only if they get a request packet from a v5 client.

Martin