[ntp:questions] WARNING: someone's faking a leap second tonight

Jeffrey Lerman jeffrey.lerman at gmail.com
Fri Aug 3 21:37:42 UTC 2012

Oh, my mistake:  I quote RFC5905 below, which is for NTPv4, which is 
technically in _draft_ status - though it does seem pretty far along and 
I believe current ntpd adheres to NTPv4, not v3.

For what it's worth the most recently approved protocol is, technically, 
NTPv3, documented in RFC1305 - and that one does say "current day" - 
though again, ntpd respects the end-of-month rule.

David Mills' website includes this page:


There one can see two things:
  - The idea to let the leap-seconds file override all else when it's 
present is already apparently implemented.  Good.
  - This text:

    "When an update is received from a reference clock or downstratum
    server, the leap bits are inspected for all survivors of the cluster
    algorithm. If the number of survivors showing a leap bit is greater
    than half the total number of survivors, a pending leap condition
    exists until the end of the current month."

Hmm.  No mention of clearing the bit if an update is received that does 
NOT show a leap bit.  I wonder if that's the problem in a nutshell.  Can 
anyone demonstrate whether ntpd clears the bit if it is set but an 
upstream server is configured and sends an LI=00 update?


On 8/3/2012 2:04 PM, Jeffrey Lerman wrote:
> That page appears to be out-of-date.  The current protocol, for NTP 
> version 4, is here: http://www.ietf.org/rfc/rfc5905.txt
> Note that there was a change from the earlier version, which did say 
> "current day".  Also, the LI ("Leap Indicator") field is only used to 
> indicate presence/absence of an impending leap second.
> The current doc says in part:
>     The fields and associated packet variables (in parentheses) are
>     interpreted as follows:
>     LI Leap Indicator (leap): 2-bit integer warning of an impending leap
>     second to be inserted or deleted in the last minute of the_*current
>     month*_with values defined in Figure 9.
>             +-------+----------------------------------------+
>             | Value | Meaning                                |
>             +-------+----------------------------------------+
>             | 0     | no warning                             |
>             | 1     | last minute of the day has 61 seconds  |
>             | 2     | last minute of the day has 59 seconds  |
>             | 3     | unknown (clock unsynchronized)         |
>             +-------+----------------------------------------+
>                           Figure 9: Leap Indicator
> Technically, there should be no need for the 2-week buffer I 
> suggested.  However, it shouldn't hurt, and seems likely to add 
> robustness.  The true correct solution would be to ensure that ntpd 
> clients pay as much attention to LI=00 from a server as to LI != 00 
> (and to fix the bug Martin filed, in which the LI field goes to 00 in 
> the last second BEFORE the leap second - oops).  Then they would be 
> able to recover gracefully from a brief persistence of the LI=01 value 
> past the leap second - assuming that no stratum 1 servers erroneously 
> persisted the LI value.  We really need to understand why that is 
> happening - do we have version info from the servers that are still 
> doing that?
> Another suggestion... Should ntpd require that a stratum-1 server has 
> a non-expired leap-second file, and that that file should override any 
> upstream server for the LI data?
> --Jeff
> On 8/3/2012 11:48 AM, E-Mail Sent to this address will be added to the 
> BlackLists wrote:
>> Martin Burnicki wrote:
>>>> clients to independently set LI=00 during, say the first
>>>>   half of the month, and to ignore the LI value from
>>>>   servers during that time.
>> I think you would have to be more exact than that.
>>   LI is used for more than one thing.
>> <http://www.eecis.udel.edu/~mills/ntp/html/decode.html>
>>    According to the doc, LI only applies to the current day?

More information about the questions mailing list