Кратко

  • В ACSP 2026.3 сообщалось: если уже есть ROA /16 с maxLength /24, то для того же Origin AS длины от /16 до /24 избыточны, а ROA для диапазона от /25 до /32, по результатам описанного теста, создать можно.
  • ARIN обновила FAQ и закрыла предложение как выполненное, но нынешняя фраза «any prefix covered» не сохраняет ни запрещённый диапазон, ни разрешённый контрпример.
  • Версионированная квитанция из пяти семантических тестов могла бы доказать единое правило для веб-интерфейса, REST и OT&E, не раскрывая код, ключи и данные клиентов.

Сначала — о том, что сработало

Chris Woodfield подал предложение ACSP 2026.3 13 января 2026 года. Это было не расплывчатое недовольство документацией. Автор процитировал спорный пример, описал наблюдавшееся поведение, выделил точную границу и предложил готовую замену.

18 февраля ARIN сообщила, что обновила FAQ, чтобы устранить путаницу, и закрыла предложение как выполненное. Около пяти недель — достойный срок для публичного механизма обратной связи. Имя автора, исходная аргументация и ответ организации сохранились; конкретный запрос не растворился в бессрочном внутреннем плане.

У отказа от избыточных ROA есть и убедительная продуктовая логика. После появления автоматического продления больше не требуется создавать второй объект с теми же полномочиями перед истечением первого. Записи, не добавляющие разрешения на анонс, загромождают список и увеличивают вероятность изменить или удалить не тот объект. Краткая FAQ для широкой аудитории тоже имеет право не повторять весь стандарт.

Поэтому вопрос не в том, может ли ARIN применять более узкое правило приёма, чем допускает общий формат RPKI. Может. Вопрос в другом: какие публичные данные связывают признанную неоднозначность со статусом «выполнено»?

В предложении уже был готов приёмочный тест

Старая формулировка, приведённая на странице ACSP, начиналась с ROA для /16 и maxLength /24. Она утверждала, что другой ROA для того же Origin AS нельзя создать ни для одного префикса внутри /16. Автор предложения указал, что испытание показало более узкое правило.

При том же AS новый префикс длиной от /16 до /24 уже разрешён существующим объектом и потому избыточен. Префиксы длиной от /25 до /32 по-прежнему находятся внутри адресного пространства /16, но выходят за существующий maxLength. Согласно опубликованному отчёту об испытании, отдельный ROA для них создать было можно.

Предлагаемый текст заменял «overlapping» на «redundant» и сохранял обе стороны границы. Разрешённый случай не был лишней подробностью: он отделял адресное включение от эквивалентности полномочий. Достаточно проверить один префикс до /24 и один после, чтобы превратить объяснение в повторяемый тест.

Нынешняя FAQ по RPKI говорит, что автоматическое продление устранило потребность в дубликатах, а ROA больше не могут перекрываться. Для /16 с maxLength /24 она утверждает, что новый ROA с тем же Origin AS будет запрещён для «any prefix covered in the existing ROA». Интервал от /16 до /24 не указан, а контрпример от /25 до /32 исчез.

Это доказательство изменения текста, но не ошибки реализации. В рамках исследования не использовалась клиентская учётная запись и не выполнялся аутентифицированный запрос в производство. Январское поведение описал заявитель; это не новый независимый эксперимент. Внутренние тесты ARIN могут полностью соответствовать ожидаемой границе, а covered in может быть обычным сокращением для «уже разрешён». Публичная страница лишь не позволяет однозначно подтвердить такую трактовку.

В RPKI покрытие и соответствие — разные проверки

RFC 6811 разделяет близкие отношения. Префикс маршрута считается Covered записью VRP, когда префикс VRP совпадает с ним или менее специфичен и соответствующие биты адреса одинаковы. Максимальная длина на этом этапе не проверяется. Matched требует дополнительно, чтобы длина маршрута не превышала максимум VRP, а Origin ASN совпадал.

FAQ не выделяет covered как нормативный термин и, возможно, использует обычный английский. Но технический читатель видит обе трактовки. /25 внутри /16 покрыт по адресу, однако не соответствует VRP /16 с maxLength /24, даже при том же ASN. Пропавший контрпример как раз разводил эти понятия.

RFC 6482 определяет maxLength на уровне подписанного объекта: это наиболее специфичная длина, которую указанный AS вправе анонсировать; без поля разрешён только точный префикс. RFC также допускает, чтобы валидный ROA содержал префикс, охваченный другой записью, и даже одинаковые записи. Дубликат с более коротким maxLength, не дающий новых полномочий, лишь не рекомендуется.

Это не означает нарушения стандарта со стороны ARIN. Валидность объекта, результат проверки маршрута и приём входного запроса сервисом — три разных уровня. ARIN вправе поддерживать более чистое подмножество. Но именно потому, что это выбор продукта, а не неизбежный вывод из RFC, его границу стоит публиковать как проверяемое правило сервиса.

Три публичные поверхности не доходят до предиката

Руководство ARIN по ROA называет Origin AS, префикс и максимальную длину, затем повторяет запрет дубликатов и перекрытий и отсылает к FAQ. Таблицы граничных случаев там нет.

Руководство по RPKI REST описывает единую транзакцию для создания, изменения и удаления ROA. Её можно атомарно объединить с операциями ASPA: либо удаётся всё, либо не удаётся ничего. В нагрузке есть startAddress, cidrLength и необязательный maxLength. Для ошибок дана ссылка на общий список, но сохранённая страница не формулирует полный критерий дубликата или перекрытия.

Атомарность создаёт отдельный граничный случай. Если транзакция удаляет старый ROA и добавляет замену, относительно какого состояния проверяется избыточность: исходного, желаемого конечного или внутреннего промежуточного? Реализация должна выбрать согласованную модель. Клиенту для предварительной проверки нужна та же модель, иначе один спорный элемент отклонит всю транзакцию.

Среда OT&E позволяет проводить такой опыт без изменения производства. По описанию ARIN, она имеет тот же набор функций, разрешает создавать тестовые ROA и проверять нагрузки RPKI-транзакций. При этом она отделена от производства, ежемесячно заменяет данные снимком, не поддерживает почтовые взаимодействия и не отслеживается сотрудниками постоянно.

OT&E — место воспроизведения, но не долговечная спецификация. После обновления меняется начальное состояние, после релиза может измениться поведение. Тест без сохранённых кортежей, ожидания, версии и даты быстро снова становится устным опытом.

Достаточно квитанции из пяти строк

В заголовке квитанции нужны номер предложения, редакция документа, версия правила и дата вступления в силу. Каждая строка указывает канал, существующие Origin AS, префикс и maxLength, новый запрос, ожидаемый приём или отказ и стабильный код причины. Версия OT&E, дата проверки и ссылка на заменившую редакцию обеспечат историю.

Пять случаев: тот же префикс и AS; более специфичный префикс в пределах maxLength; префикс за пределами maxLength; тот же адресный диапазон с другим Origin AS; атомарное удаление старого объекта и добавление замены. Документационных сетей и зарезервированных ASN достаточно, поэтому данные клиентов, ключи производства и исходный код не нужны.

FAQ может остаться короткой. Квитанция возьмёт на себя точность и разделит три утверждения: текст изменён; сервис так обрабатывает эти кортежи; статус «выполнено» действительно означает поставку запрошенного уточнения.