Кратко

  • 8 сентября 2026 года APNIC и NIXI подписали меморандум о содействии внедрению ROV в Индии, пилотном зеркале репозитория RPKI и местной учебной инфраструктуре. Само объявление еще не подтверждает изменения боевой маршрутной политики.
  • APNIC поставила рядом покрытие действующими ROA — 88,04% маршрутных объектов IPv4 и 97,91% IPv6 — и показатель ROV 0,99%, названный долей фильтрующих сетей. Однако связанная методика ориентирована на пользователей и обычно не позволяет установить, отфильтровала маршрут пограничная или транзитная сеть.
  • Проверяемый отчет должен раздельно хранить пять поверхностей: ROA, оконные наблюдения I-ROV, фактическую область конфигурации операторов, охват трафика и путей, а также вспомогательные результаты вроде зеркала и обучения. Связывать их следует по когорте и дате.

Четыре числа вместо одного

В строке индийского временного ряда APNIC Labs за 8 сентября 2026 года значение filter_rate для семидневного окна равно 1,138930. Для 14 дней оно составляет 1,147895, для ключа 28 — 2,135396, для 112 дней — 6,031948.

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

В описании набора есть и неустраненная формальная разница. Там перечислены окна 7, 14, 38 и 112 дней, тогда как в объектах данных стоят ключи 7, 14, 28 и 112. Зафиксированные источники не дают оснований по усмотрению заменить 38 на 28 или наоборот. В отчете надо указывать фактический ключ и сохранять расхождение описания с полезной нагрузкой.

В тот же день APNIC и National Internet Exchange of India подписали меморандум на APNIC 62 в Мумбаи. По сообщению APNIC, организации будут помогать сетевым операторам и предприятиям внедрять Route Origin Validation. В программу также входят пилот зеркала репозитория RPKI в Индии, местные лаборатории, подготовка инструкторов, очное и дистанционное обучение.

Это разумная последовательность поддержки, но не один и тот же результат. Зеркало может улучшить условия получения подписанных данных. Курс формирует навыки. ROA публикует полномочия источника. Валидатор вычисляет состояние. Решение отклонить недействительный маршрут появляется лишь тогда, когда оператор явно задает его в своей политике.

Подпись не принимает решение за маршрутизатор

RFC 6811 определяет состояния Valid, Invalid и NotFound. Он же требует не исключать маршрут из процесса выбора только вследствие состояния валидации, если такое поведение не было явно настроено. Отклонение Invalid, снижение предпочтения, исключения и поэтапное включение — локальные решения оператора.

Эта граница определяет смысл высоких индийских показателей ROA. В статье от 17 августа APNIC сообщает, что к концу июля действующей ROA были охвачены 88,04% маршрутных объектов IPv4 и 97,91% объектов IPv6. Это существенный прогресс на стороне подписанных полномочий владельцев ресурсов.

Но он не означает, что 88,04% индийских сетей отбрасывают недействительные объявления. Он не показывает, какая доля пользователей, трафика или путей проходит через такую политику. Владелец адресного ресурса и сеть, принимающая маршрут, могут быть разными организациями. Покрытие подписью нельзя автоматически переносить на исполнение.

Та же статья характеризует 0,99% как долю сетей, фильтрующих недействительные префиксы и объявления на 29 июля. В семидневном окне исходного ряда действительно стоит 0,990652. Однако методика APNIC Labs прямо говорит, что исследователи не видят состояние BGP внутри каждого автономного системы и потому используют измерение, ориентированное на пользователя.

Управляемые цели объявляются маршрутами, статус ROA которых меняется с Valid на Invalid и обратно. Если в период Invalid пользователь не достигает цели, наблюдение совместимо с тем, что маршрут был отброшен где-то на пути. Это полезное свидетельство пользовательского опыта. Оно не является переписью конфигураций всех AS.

Методика отдельно предупреждает об атрибуции. По мере распространения фильтрации в транзитных сетях труднее увидеть поведение сети доступа. Пользователь может оказаться защищен благодаря upstream-оператору, хотя его собственная сеть не применяет ROV. И наоборот, оператор может включить политику лишь на некоторых пограничных маршрутизаторах или классах сессий, сохранив исключения и откат.

Поэтому недоступность тестовой цели не превращается автоматически в подсчитанный AS. Заявление одного AS о внедрении не распространяется на все его пути. Действующая ROA не равна фильтру. Все эти показатели нужны, но у каждого свой знаменатель.

Ставка на крупнейшие сети

Генеральный директор NIXI предлагает более содержательную гипотезу, чем простой подсчет операторов. В сообщении APNIC ему приписывается утверждение, что небольшое число крупных сетей переносит большую часть интернет-трафика Индии, поэтому внедрение ROV именно ими может заметно защитить маршрутизацию всей экономики.

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

Но опубликованный текст не называет операторов, не приводит их доли трафика и метод расчета, не определяет границы «индийского трафика». Неизвестно, будут ли одинаково охвачены клиентские, пиринговые и транзитные сессии. Пока это теория изменений, а не измеренный итог.

Крупный оператор не равен одному пути. У него несколько upstream-провайдеров, точек обмена, частных стыков и продуктовых границ. Политика на одном рубеже не гарантирует, что ее встретит каждый пользователь. Проверка концентрационной стратегии требует связать названную когорту, область конфигурации и фактический охват путей или трафика.

Пять отдельных частей квитанции

Утвержденный Советом План деятельности APNIC на 2026 год уже требует измеримого эффекта. В нем отдельно названы помощь членам в создании и поддержании действующих ROA и ее измеримое воздействие, а также помощь выявленным операторам во внедрении ROV и ее измеримое воздействие. Использование RPKI в Азиатско-Тихоокеанском регионе должно публиковаться каждые шесть месяцев.

Первая часть — покрытие ROA: IPv4 и IPv6 отдельно, единица — маршрутный объект или адресное пространство, состояния Valid/Invalid/NotFound, дата среза и версия. Она подтверждает опубликованные полномочия.

Вторая — наблюдение I-ROV: метод тестовых целей, географическое отнесение, счетчики, окно, обновление и предел атрибуции между edge и транзитом. Она подтверждает ограниченный опыт пользователя и пути.

Третья — политика оператора: устойчивая когорта, ASNs или ограниченное число, дата включения, версия правил, охваченные клиентские, пиринговые и транзитные сессии, исключения и статус отката. Секретную топологию можно агрегировать, но смысл «внедрено» должен остаться проверяемым.

Четвертая — охват: метод оценки доли трафика, пользователей или путей, обработка контролируемых Invalid-объявлений, инциденты, исключения и период наблюдения. Здесь проверяется тезис NIXI о крупнейших сетях.

Пятая — вспомогательные результаты. Зеркало оценивается по исходным и целевым параметрам доступа и устойчивости. Обучение делится на участие, выполнение лабораторной работы, запланированное изменение, изменение в производстве и сохраненную конфигурацию. Эти успехи не нужно выдавать за фильтрацию, чтобы признать их ценность.

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

Чего данные пока не доказывают

На дату исследования меморандуму был один день. Нет доказательств изменения политики у названного индийского оператора. Нельзя вычитать 0,99% из 88,04% или делить их друг на друга. Разброс сентябрьских окон не доказывает внезапное внедрение.

Зеркало репозитория не выполняет ROV; валидатор не навязывает решение маршрутизатору. ROV проверяет полномочия источника, а не весь AS-путь, и само по себе не предотвращает каждую утечку или перехват. Точная граница не ослабляет программу: она делает будущий результат проверяемым.

Источники