Кратко

  • IRR Auto-Manager может создать или связать объект маршрута IRR при создании ROA, но затем оставляет пользователю независимые варианты удаления и сохранения обеих записей.
  • ACSP 2026.9 просит дать действиям IRR историю, сопоставимую с журналом ROA. Два похожих списка улучшат видимость, но сами по себе не докажут, какие строки относятся к одному намерению.
  • Ограниченная квитанция межреестровой операции может связать исходное состояние, выбор, кратность, результат и исправление, сохранив различие между авторизацией ROA и декларацией RPSL.

ARIN решила задачу, которая редко выглядит значительной, но регулярно отнимает время. Route Origin Authorization и объект маршрута в Internet Routing Registry относятся к одной паре префикса и исходной AS, однако создаются в разных системах и несут разный смысл. Двойной ввод означает не только лишнюю работу, но и дополнительную возможность забыть об изменении. IRR Auto-Manager включает создание подходящего объекта route или route6 в процесс создания ROA и связывает записи.

Сначала стоит признать сильную сторону решения. Автоматизация сокращает повторение, не лишая владельца ресурсов выбора. Ее можно отключить для Org ID. Даже при включенной настройке пользователь вправе отказаться от создания объекта IRR в отдельной операции. Если уже существует совпадающий неуправляемый объект, его можно заменить автоматически управляемым или оставить без изменений. Для существующих ROA инструмент Sync Up умеет создать недостающий объект либо связать уже имеющийся.

В конструкции предусмотрен и выход. Объект IRR можно удалить независимо, не затрагивая ROA. При удалении ROA пользователь выбирает, удалить ли связанные объекты или сохранить их в неуправляемом состоянии. Если ROA содержит несколько префиксов, для каждого создается отдельный объект IRR. Связь облегчает координацию, но не становится вечной и не обязательно остается отношением один к одному.

Сами записи неравнозначны. ROA — подписанная авторизация исходной AS; она может содержать maxLength, задающий предел длины более специфичных разрешенных объявлений. Объект маршрута IRR — декларация RPSL с префиксом и исходной AS. Auto-Manager использует запись префикса и не превращает maxLength в набор более специфичных объектов IRR. Это не забытое поле, а сохраненная граница между авторизацией и декларацией.

Ту же границу видно в API. При создании roaSpec:autoLink определяет, будут ли ресурсы ROA связаны с подходящими объектами route или route6 и созданы ли они при необходимости. Поле autoLinked в ответе сообщает результат. API IRR при этом продолжает отдельно управлять собственными объектами. Общая операция не превращает две модели данных в одну.

У нынешнего подхода, таким образом, есть убедительная защита. ARIN автоматизировала узкую координацию, оставила отказ и выход, не стерла смысловые различия. Следующий вопрос касается доказательства: охватывает ли видимая история весь путь, который теперь проходит одна операция?

Что уже показывает история ROA

Документация ARIN описывает Origin AS/Prefix Pair Change Log для новых и измененных ROA организации за последние 365 дней. История длиннее ста элементов разбивается на страницы. В таблице есть время, операция, источник, исходная AS, префикс, максимальная длина и Changed By. Операция принимает значение Added или Removed, источник — Web User, API User или ARIN System. Полный CSV можно запросить через заявку. ARIN обещает рассмотреть запрос и ответить в течение двух рабочих дней, после чего файл доступен для скачивания 90 дней.

Это больше, чем перечень текущих объектов. История связывает добавление или удаление пары AS-префикс со временем и источником. Она отличает действие в веб-интерфейсе от вызова API и от действия системы ARIN. Изменение можно представить удаленными и добавленными парами; не следует приписывать таблице отдельное публичное значение Modified, которого документация не называет.

Для объектов IRR проверенная публичная документация не описывает сопоставимой видимой истории действий. 11 мая 2026 года Randal Kohutek подал предложение ACSP 2026.9 и попросил добавить журнал действий IRR, равный журналу ROA. Формулировка была осторожной: система IRR, по его наблюдению, «не выглядит» имеющей такую историю. Это не доказательство отсутствия внутренних журналов, истории базы данных или средств безопасности и поддержки ARIN.

19 мая ARIN согласилась, что функция принесет пользу клиентам, которым нужно отслеживать действия с объектами IRR. Предложение добавили в дорожную карту безопасности маршрутизации для будущей разработки, передали во внутренний процесс приоритизации и планирования реализации, а затем закрыли. Признать потребность и определить процесс за восемь дней — конструктивная реакция. Но это не дата выпуска, не схема, не гарантия реализации и не свидетельство уже работающей функции.

Одинаковые колонки еще не дают общей причины

Будущая история IRR со временем, источником, пользователем и действием устранит очевидную асимметрию. У оператора появятся две временные линии. Главный вопрос расследования останется прежним: какие строки появились из одного решения?

При создании ROA система может обнаружить существующий неуправляемый объект. Его можно заменить или оставить. Несколько префиксов порождают несколько объектов. Позже объект IRR можно удалить отдельно, сохранив ROA. При удалении ROA связанные объекты либо исчезают, либо остаются неуправляемыми. Sync Up может создать новое или только связать существующее. Каждая ветвь дает итоговое состояние, которое не рассказывает собственную историю.

Близость времени помогает искать, но не доказывает причинность. Две строки в одну секунду могут относиться к разным запросам. Два события с промежутком могут быть частями одной операции с подтверждением. Отсутствие объекта не сообщает, какой вариант удаления был выбран. Наличие объекта не объясняет, оставили ли его намеренно или создали заново.

Даже нынешнее совпадение значений не доказывает непрерывной связи. Объект IRR могли удалить независимо, а затем восстановить через Sync Up, после чего экран снова показывает согласованное состояние. Сравнение значений отвечает на вопрос «что есть сейчас». Происхождение операции отвечает на вопрос «почему состояние стало таким». Эти функции нельзя подменять друг другом.

Объяснение нужно и без известного инцидента. ROA могут служить подписанным входом для проверки происхождения RPKI. Данные IRR могут участвовать в формировании или проверке фильтров маршрутной политики. Ни одна запись не доказывает, что было объявлено в BGP и что принял конкретный маршрутизатор. Но при расхождении инженеру все равно нужно отличить явный отказ, старый объект, независимое удаление, связь один ко многим, частичный результат и последующее исправление.

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

Квитанция следует за действием

В начале достаточно непрозрачного идентификатора операции и времени. Квитанция указывает исходную поверхность — ARIN Online, RPKI API, IRR API, Sync Up или ARIN System —, класс действующего лица и авторизованную организацию, не публикуя личное имя без необходимости. Намерение тоже структурировано: создать или изменить ROA, удалить ее, создать или связать объект IRR, заменить неуправляемый объект, удалить только IRR, сохранить его неуправляемым либо синхронизировать заново.

Далее связываются состояния до и после. На стороне ROA это идентификатор, исходная AS, префикс и maxLength. На стороне IRR — ключ route или route6, префикс, источник, управляемое состояние и состояние связи. При нескольких префиксах фиксируется кратность. Если объект существовал заранее, квитанция прямо сообщает, был ли он использован, заменен или оставлен без изменений.

Решение о выходе требует отдельного поля. «Удалить ROA и связанные объекты» не равно «удалить ROA и сохранить объекты неуправляемыми». Итоговое отсутствие не должно быть единственным доказательством. Если одна сторона выполнена, а другая нет, квитанция разделяет результаты и сообщает, достигнуто ли ожидаемое конечное состояние. Исправление указывает на замененную квитанцию, а не стирает прежнее объяснение текущим значением.

Необязательно публиковать ключи API, постоянные личные имена или историю другой организации. ARIN может хранить больше деталей во внутренних средствах безопасности, выдавать структурированную квитанцию авторизованному владельцу и публиковать схему, срок хранения, правила выгрузки и версии. Проверяемость в аутентифицированном отношении не означает неограниченную открытость.

В Auto-Manager уже заложена правильная институциональная сдержанность: координировать, не сливая; автоматизировать, не закрывая выход. ACSP 2026.9 отмечает следующий шаг. Лучшее решение не просто скопирует колонки истории ROA. Оно позволит доказать, когда два изменения были одной операцией, а когда стали независимыми выборами, не заставляя отметку времени утверждать то, чего она доказать не может.

Источники