Стандарт NTPv4: внедрить сервер NTP, чтобы проверить, обрабатывает ли утилита ntpdate проблему с опрокидыванием 2036

Question

Я хотел бы проверить, обрабатывает ли утилита ntpdate из NTP проблему пролонгации 2036 года. Для этого я хотел бы реализовать NTP-сервер, который генерирует временную отметку c по истечении времени пролонгации: 2036-02-07 / 06: 28: 15.

В настоящее время я застрял на точка понимания того, как NTP решает эту проблему. Я вижу, что протокол NTPv3 использует 64-битные метки времени (32-битные секунды, 32-битное использование c (дробь)), и я также вижу, что новый стандарт NTPv4 определен в rfc5905 page12 решает эту проблему, определяя три различных типа данных.

Существует три формата времени NTP, 128-битный формат даты, 64-битный формат отметки времени и 32-битный короткий формат

Но в определенном «формат заголовка пакета», определенный в стр. 18 , используемая временная метка содержит только 64-битный формат временной метки. В документе нет других упоминаний о том, как мы можем включить «128-битный формат даты», который включает в себя данные «эры» и «смещения эры», определенные для решения проблемы пролонгации.

Утилита "ntpdate" утверждает, что поддерживает стандарт NTPv4, поэтому я предположил, что она должна поддерживать и 128-битные метки времени. Я также просмотрел исходный код ntpdate , чтобы узнать, есть ли какая-либо поддержка форматов "эра" или "128-битная метка времени", но я не смог найти указателей, которые бы указывали, что ntpdate может обрабатывать 128-битные метки времени.

Насколько я понимаю, NTP представил протокол NTPv4, 128-битный формат даты, который должен использоваться для решения проблемы пролонгации. Правильно ли мое понимание? и есть ли какие-либо другие серверы с открытым исходным кодом, доступные онлайн, чтобы исследовать поведение утилит 'ntpdate' или 'ntpd' для проблемы пролонгации 2036?

Заранее спасибо!

Answer 1

После долгих исследований я смог придумать эту ссылку , где проблема объяснена четко.

Оказывается, мы всегда можем отправить только отметку времени в 64-битном формате, как определено, не заботясь об эпохе. В Charpter 6 из rfc5905 дается объяснение того, как определить метку времени из времени прайм-эпохи.

Чтобы преобразовать системное время в любом формате в дату NTP а для форматов меток времени необходимо определить количество секунд s от первичной эпохи до системного времени. Чтобы определить целое число эры и метку времени, заданные s,

эра = с / 2 ^ (32) и метку времени = s - эра * 2 ^ (32)

, и то же самое объясняется с примером в приведенной выше ссылке. Я все еще удивляюсь, почему NTPv4 удосужился определить «128-битный формат даты» и где именно он используется, но это не является предметом этого вопроса.

Также возможные ограничения, которые необходимо добавить здесь: эти вычисления будут работает только в течение прошедших эпох и только в том случае, если клиент настроен на сервер в течение 68 лет из-за подписанного arthemati c. Цитирование из Раздел 6, Страница 5

Фактически, если клиент установлен в течение 68 лет с момента запуска сервера до запуска протокола, правильные значения получаются, даже если клиент и сервер находятся в соседних эпохах.

Спасибо!