Кратко

  • RFC 8210 определяет номер как циклически возрастающую логическую версию в пределах одной линии кэша; номера разных кэшей, сессий и версий протокола несопоставимы.
  • Полное получение данных маршрутизатором, сессия, таймеры обновления и истечения, а также наблюдения проверки вышестоящих данных — отдельные свидетельства, не выводимые из номера.
  • Для контроля свежести нужен журнал синхронизации с временем наблюдения, а не глобальная сортировка кэшей по номеру.

Сравнение выглядит просто: кэш A сообщает 90 000, а кэш B — 12 000. Панель сортирует числа и отмечает A как более новый. Оба значения могут быть верны, но вывод остаётся недоказанным.

RFC 8210 определяет Serial Number как строго возрастающее беззнаковое 32-битное число с циклическим переходом. Оно обозначает логическую версию одного кэша. Значение увеличивается после успешного обновления из родительского кэша или первичных данных RPKI; данные новой версии нельзя отдавать до завершения этой загрузки.

Это порядок лишь в правильных границах. Тот же RFC прямо говорит, что номера разных кэшей и версий протокола несоизмеримы и не обязаны сохраняться после сброса. Session ID определяет экземпляр кэша и связывает последовательность его номеров. Для сравнения нужны версия протокола, Session ID и номер вместе.

Следовательно, номер — позиция в локальной последовательности, а не универсальные часы. Только что запущенный кэш может иметь актуальные данные при малом номере. Давно работающий кэш может показывать большое число, хотя его последнее успешное обновление сверху произошло раньше. Сравнение голых чисел отбрасывает идентичность, придающую им смысл.

Обмен между маршрутизатором и кэшем задаёт ещё одну границу. Маршрутизатор отправляет Serial Query и просит изменения после текущего значения. При достаточной истории кэш возвращает минимальный объединённый набор для синхронизации. Иначе он требует Cache Reset и полную передачу. Номер из End Of Data PDU становится текущим у маршрутизатора только после получения полного ответа.

Это событие завершения принципиально. Кэш уже может перейти к новой логической версии, а маршрутизатор ещё не получить её. Уведомление лишь предлагает выполнить запрос. Текущий номер маршрутизатора подтверждает последний полностью полученный набор именно от этого кэша, а не самое новое состояние где-либо ещё.

RFC 8210 также отделяет время от последовательности. Интервалы Refresh и Retry управляют следующими запросами. Expire ограничивает срок использования прежних данных без нового успешного запроса. Отсчёт начинается при получении End Of Data. Серийный номер не показывает остаток этого срока.

Манифесты репозитория подтверждают различие. RFC 9286 использует монотонно растущий manifestNumber, но отдельно содержит thisUpdate и nextUpdate и предусматривает проверки просроченных либо преждевременно выпущенных манифестов. Даже в одной линии публикации порядок версий и временная действительность — разные доказательства.

Полезный журнал свежести должен сохранять идентичность кэша, версию протокола, Session ID, номер, время успешного получения End Of Data, значения Refresh, Retry и Expire, последнее успешное наблюдение проверки вышестоящих данных, а также контекст якорей доверия и политики. Время манифеста репозитория следует записывать отдельно, не угадывая его по номеру RTR.

Так становятся видны и пределы знания. Маршрутизатор может доказать, что полностью получил номер 200 сессии X в 10:04 и данные ещё не истекли. Но это не доказывает, что другой кэш не видел более позднего состояния, все репозитории сошлись или другой маршрутизатор одновременно получил ту же нагрузку.

Здесь не утверждается, что произошёл отказ кэша или инцидент с устаревшей маршрутизацией. Речь о границах доказательства: номер полезен именно потому, что упорядочивает состояния в сопоставимой линии. Использование его как глобального времени убирает контекст, делающий его надёжным.

Источники