Кратко

  • В дорожной карте APNIC на III квартал 2026 года есть пункт «Route management alignment»: после передачи ресурсов, их вывода из распределения и системных изменений организация намерена автоматически согласовывать управление маршрутами, держателя, Whois и RPKI.
  • Эти уровни отвечают на разные вопросы. Запись о ресурсе определяет административное полномочие, объект IRR публикует политику или намерение, ROA разрешает origin AS, а BGP показывает наблюдаемый маршрут, который каждая сеть оценивает по своей политике.
  • Публичный пункт не определяет приоритет при конфликте, границу транзакции, состояние частичного успеха, уведомление и доказательство rollback. Это пробел публичного описания, а не доказательство отсутствия внутренней архитектуры у APNIC.
  • Матрица полномочий по типам записей и версионированная квитанция каждой задачи позволят уменьшить ручную работу, не стирая допустимые различия, предыдущее состояние и путь к последней безопасной точке.

Аккуратная база может скрывать неверное решение

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

Пункт APNIC «Route management alignment» относится к команде Registry, намечен на Q3 2026 года и помечен продуктами ARMS, RPKI и Whois. В кратком описании говорится об автоматической сверке управления маршрутами с держателями ресурсов и синхронизации Whois и RPKI. Цель — сократить утомительную и подверженную ошибкам ручную работу после transfers, deallocations и системных изменений.

Цель полезна. Сеть не становится надёжнее от того, что оператор несколько раз вводит один префикс и ASN в разных интерфейсах. Во время передачи ресурса каждая ручная операция повышает риск пропуска или неправильной последовательности.

Однако слово alignment объединяет данные с разным смыслом. Когда они расходятся, код принимает решение: сохранить, удалить, отложить, заменить или направить на проверку. Такое решение влияет на право управления ресурсом, на объекты, из которых строят фильтры, и на авторизации, с которыми валидаторы сравнивают маршруты.

В зафиксированной структурированной записи дорожной карты есть год, квартал, команда, продукты, резюме и предлагаемое решение. Поле changelog пусто. Публичное описание не называет precedence, границу многошаговой транзакции, модель частичного сбоя, rollback, уведомление участника, а также границы с NIR и внешними IRR. Возможно, APNIC уже прорабатывает всё это внутри. Доказательства не позволяют утверждать обратное. Они позволяют сказать лишь, что публичное обещание пока не содержит правил выбора.

Четыре системы свидетельствуют о разном

Держатель ресурса — это факт реестра. Он отвечает на вопрос, какой аккаунт или организация признаны полномочными управлять адресным блоком либо ASN. При transfer такое полномочие меняется. Но запись не сообщает сама по себе, какой AS должен анонсировать каждый префикс сегодня.

Internet Routing Registry описывает политику. APNIC называет IRR распределённой совокупностью баз, где операторы публикуют routing policy и объявления, чтобы другие сети могли создавать фильтры и конфигурации. RFC 2725 требует при создании route object проверять авторизацию как для адресного префикса, так и для origin AS. Стандарт учитывает несколько origins для одного префикса, перекрывающиеся more specifics, смену провайдера и переходный период перенумерации.

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

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

BGP предоставляет наблюдение. RFC 6483 описывает, как сравнить префикс и origin AS принятого маршрута с действительными ROAs и получить Valid, Invalid либо Unknown. Решение о дальнейшей обработке остаётся частью local routing policy. Реестр может публиковать разрешение, но не управляет выбором каждого чужого маршрутизатора.

Даже время у этих систем разное. RFC 6483 отмечает, что объекты RPKI и маршруты могут распространяться с разной скоростью. Новая ROA может быть опубликована, но ещё не попасть в локальный cache. Объявление может появиться раньше обновлённой авторизации. Резервный AS может быть разрешён, но не активен. Краткое расхождение бывает формой безопасного перехода.

Запись о держателе, IRR object, ROA и BGP — свидетельства полномочия, намерения, разрешения и поведения. Связь между ними не делает их взаимозаменяемыми.

Старый интерфейс сохранял конфликт как событие

Route Management Guide APNIC 2017 года показывает предшественника нынешней задачи. Возраст документа не позволяет считать его действующей спецификацией проекта 2026 года. Но в нём есть принципиальное различие между управляемым состоянием MyAPNIC и публичным route object в Whois.

«Route» внутри MyAPNIC служила шаблоном для создания фактического объекта Whois. Они могли существовать отдельно: шаблон без публичного объекта или объект без управляемого шаблона. Если Whois меняли по другому каналу, MyAPNIC не перенимал правку молча. Интерфейс показывал conflict, после чего пользователь принимал внешнее изменение либо возвращал объект к шаблону.

Различие становилось видимым фактом. Возможно, авторизованный maintainer внёс срочное исправление. Возможно, осталась устаревшая запись. Система не уничтожала след другого канала прежде, чем пользователь мог осмыслить причину.

Руководство также описывает pending при синхронизации нескольких объектов. Пользователь с нужными правами мог при создании маршрута включить соответствующие ROAs. В одном сценарии удаления отключение управляемого sub-route с активной ROA удаляло и эту ROA. Уже тогда единый экран объединял разные полномочия, фоновые задачи и необязательные связи.

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

«Транзакционно, где возможно» — точное ограничение

Объявление APNIC Registry API в октябре 2024 года даёт более свежий контекст. API получает сведения о делегировании и управляет Whois, reverse DNS, ROAs и route objects. В качестве примера APNIC описывает автоматическое создание ROA и route object при добавлении объявления BGP.

Механизм сформулирован с важной оговоркой. Абстрактные операции управления маршрутами и reverse DNS можно отправлять пакетами, которые действуют «transactionally where possible». Все изменения представлены асинхронными task objects: клиент получает ссылку, проверяет статус и затем читает подробный результат.

«Где возможно» признаёт границу атомарности. Несколько записей в одной базе могут иметь общий commit. Публикация в RPKI repository, получение независимыми validators, изменение у другого RIR, объект во внешнем IRR и перестроение фильтра у провайдера принадлежат разным доменам. Общий API не превращает их в одну транзакцию.

Поэтому план сверки должен описать область, где атомарность невозможна. Если Whois обновлён, а запланированная ROA не создана, общего Failed недостаточно. Повтор всего запроса может повторно выполнить уже успешный шаг. Результат должен назвать завершённое действие, ошибку, последнюю безопасную точку, условие retry, quarantine и compensating action.

Completed тоже не означает, что все caches и сети увидели результат. Это может означать окончание действий, контролируемых APNIC. committed, published и observed — разные состояния.

В статье не проверялся текущий сбой Registry API. Объявление важно по другой причине: APNIC уже публично использует понятия batch, ограниченной транзакции, асинхронной задачи и результата. На них можно построить прозрачную модель нового согласования.

Передача меняет право, но не пишет новую маршрутную политику

Действующие APNIC Transfer Conditions говорят, что при исходящей inter-RIR передаче связанные с ресурсом sub-assignments, route objects и domain objects удаляются из APNIC Whois Database. После завершения исходная организация утрачивает права на IP-адреса и ASN, а ресурсы регистрируются за получателем.

Цитируемое условие перечисляет объекты Whois. Оно не сообщает, что происходит с ROAs. Нельзя превращать молчание в утверждение об их удалении. Эта граница как раз разделяет два решения: прекращение полномочий и очистка исходного Whois не определяют авторизацию, которую хочет создать новый держатель.

Если получатель оставляет тот же origin AS, держатель меняется, а маршрутное намерение, возможно, нет. Если он переходит на новый AS, новую авторизацию может потребоваться подготовить до отзыва старого пути. Если передача идёт в другой RIR, удаление в источнике и видимость у получателя подчиняются разным часам. Это аналитические сценарии для проверки, а не сообщения об инцидентах APNIC.

Удалить всё первым шагом — значит рискнуть создаваемым Invalid или NotFound окном. Хранить всё без срока — продлить старое полномочие. Копировать увиденный BGP в ROA — превратить поведение в разрешение без решения владельца. Универсальный порядок здесь опасен.

Слово aligned лучше разложить на этапы. prepared: изменение авторизовано, но не действует. committed: запись принята реестром. published: объект доступен на публичной поверхности. observed: независимая проверка увидела результат. retired: прежнее состояние перестало наделять полномочием. Каждый этап имеет свой источник доказательства.

Три расхождения, которые автоматизация обязана сохранить

Первое — законный multiorigin. IRR и RPKI поддерживают несколько origins. Движок должен проверять полномочия и диапазон префикса, а не принимать количество больше одного за ошибку. Иначе резервный путь исчезнет ради красивой таблицы.

Второе — задержка распространения. Запись уже committed, но ещё не published; опубликованная запись ещё не observed. Если считать каждое промежуточное состояние постоянным конфликтом, система может заново выполнить или отменить изменение, которое просто ещё распространяется.

Третье — правка через иной авторизованный канал. Старое руководство давало выбор принять внешний Whois update или восстановить шаблон. Новой системе нужно знать автора и его полномочие, новизну намерения и связь с RPKI. Если всегда побеждает шаблон, пропадёт законное срочное исправление. Если всегда побеждает внешняя правка, управляемый план утратит смысл.

Четвёртая граница связана с deallocation. Дорожная карта называет такой trigger, но не публикует последовательность. Окончание права на ресурс может потребовать отзыва, однако уведомление, срок, review и ресурсы под NIR нельзя вывести из одного слова. Внешние IRR objects не находятся в локальной области записи APNIC.

Не единый источник истины, а источник полномочия для каждого вопроса

Выражение single source of truth обещает простоту, потому что скрывает спор. Здесь нужна другая модель. Держатель определяет, кто может действовать. Аутентифицированный и авторизованный запрос выражает намерение. IRR публикует policy. ROA подтверждает origin authorization. BGP даёт наблюдение. Ни один из источников не должен самостоятельно создавать значения остальных.

APNIC может опубликовать небольшую матрицу. В строках — transfer, deallocation, прямая правка Whois, изменение шаблона маршрута, изменение ROA, системная миграция. В столбцах — уполномоченная роль, предусловия, изменяемые записи, допустимые различия, автоматические действия, trigger для ручной проверки и срок возражения.

Отдельный столбец задаст транзакционную границу. Какие записи имеют общий commit? Что публикуется асинхронно? Где начинается зависимость от другой организации? Что изолируется после частичного результата? Когда оператор может безопасно изменить объявление или перестроить filters?

Особенно важно разделить отмену старого права и создание нового намерения. Transfer может запретить исходному аккаунту редактирование. Он не уполномочивает APNIC угадывать origin AS получателя. Наблюдение BGP может вызвать сигнал, но не должно автоматически подписывать ROA.

Квитанция, которую не стирает rollback

Каждая существенная задача должна создавать версионированную квитанцию. В начале — event ID, task ID, trigger, время и snapshot держателя, использованный для проверки полномочий заявителя. Затем отдельно показаны до и после для шаблона маршрута, Whois route objects и ROAs.

У каждого изменения есть типовая precedence rule и reason code. Квитанция проводит границу транзакции: какие записи committed вместе, какая публикация осталась pending, какие системы не контролирует APNIC. При частичном успехе указаны удачный и неудачный шаги, последняя безопасная точка, условие повторения, quarantine и компенсация.

Для видимости нужны собственные времена: когда Whois стал отвечать, когда RPKI object опубликован, когда независимый validator его увидел. BGP можно приложить как сигнал, но не как команду или гарантию доступности.

Inter-RIR, NIR, deallocation и внешний IRR должны стать явными scope flags. Уведомление, подтверждение, путь review, override и ответственный сервис фиксируются без публикации ключей и лишних персональных данных. Rollback добавляет связанный результат, а не удаляет исходную задачу.

Это предложение статьи, а не уже обещанная функция APNIC. Оно не требует открыть весь внутренний журнал. Его задача уже: дать затронутой стороне отличить намеренное различие от незавершённого распространения, полный успех от частичного.

Автоматизация ручной сверки полезна. Риск возникает, когда выбор полномочия маскируется как техническая мелочь. Прежде чем код назначит победителя, APNIC следует сделать правила конфликта и результат читаемыми.

Источники