[Ntp] Re: ITU SG17 liaison on NTP rollover event

[Ruben Nijveld <[e-mail]>]

Hi all,

I've read these documents, and had previously had contact with some people about these kinds of rollover events as well. I've been thinking about this for a while now. One thing that makes this particularly relevant for NTP is that it will have the first of these larger rollover events. The issues faced by NTP are in some way smaller than the issues that will be experienced as soon as the Unix timestamp rollover happens, given that NTP timestamps are mostly limited to the NTP ecosystem and are most of the time quickly transformed to something like a Unix timestamp once an NTP client needs to update the system clock. I can see a couple of things where the NTP working group could assist:

First, we could set up a couple of testable scenarios and expected outcomes for implementers and operators to check their implementations against. This could help organization determine if they need to update their NTP implementation or if they are 'safe' from the NTP rollover event. Maybe we could publish such test cases and recommendations as an informational RFC? I feel something like that would send a stronger message to implementations and organizations about what we expect around the NTP rollover event.

Secondly, one interaction I would particularly draw attention to is the interaction with devices that don't remember their time (i.e. because they don't contain a battery) and start from a zero state every time they are started. In case such a device uses a Unix timestamp, their local date will appear to be January 1970. As the NTPv4 specification states: 
   
   In point of fact, if the
   client is set within 68 years of the server before the protocol is
   started, correct values are obtained even if the client and server
   are in adjacent eras.

This means that somewhere around the Unix rollover event, even if the device would use 64-bit timestamps (and thus would normally function regularly well beyond the 32 bit Unix rollover event), that device cannot properly synchronize time using just NTPv4 (and no additional manual input). One recommendation I would have for device manufacturers is to make sure that the zero state does not actually result in a Unix timestamp of zero, but would instead fall back to something like device manufacture date as a default value. This means that any device will always have at least a lifetime of 68 years before it becomes difficult to synchronize without additional input with NTPv4.

More in scope for the NTP WG however: I think we should try and make sure that we really get out NTPv5 by the end of the year so that we buy ourselves at least another 34 thousand years before this problem props up again. Finally, one recommendation that was in the past voiced in RFC4330 (SNTP) could maybe be pushed forward once again (as I have a feeling that many may have forgotten it or don't implement this): make sure that if you encounter a timestamp within the 1900-1970 range, increase the era by one instead, given that such timestamps are, as one might guess, exceedingly unlikely to be from that time. It might be worth it to publish such a recommendation once again to ensure that implementations understand it is a valid solution as long as they keep using NTPv4 (or older).

One final thing I'd like to add here: I think it is good if people start mentioning the 2036 and 2038 rollover events more to their peers, bosses, and anyone else who will listen. Awareness is the most important thing to ensure this gets the attention required to fix it. Let's hope we can make this as much of a dud as the Y2K scare in the end was thanks to all the hard work of people back then.

Regards,
Ruben

On Mon, 20 Jul 2026, at 15:32, Karen ODonoghue wrote:
> NTP working group members,
> 
> You will have seen in a recent email to the mailing list that we have received a liaison request from ITU SG17 (https://mailarchive.ietf.org/arch/msg/ntp/55Z1N6o7QJycgz1Ha33Lb6vfZMw/) We will be working with the IAB liaison coordinators with a response to this liaison request. I am attaching the two documents that were included in the zip file sent to us by the ITU. Discussion and comments on these documents are welcome, either to the mailing list or to Dieter and myself. 
> 
> Regards,
> Karen
> 
> 
> 
> 
> 
> 
> _______________________________________________
> ntp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 
> 
> *Attachments:*
>  • SG17-LS161.docx
>  • SG17-LS161Att.docx