Кратко
- Revision 01 документа
draft-dong-sidrops-rpki-rtr-moa-pdu, опубликованная 9 сентября 2026 года, добавила полный и частичный отзыв наборов, разделённых между PDU, а также Refresh, Retry, Expire и Serial Number. Это активный индивидуальный Internet-Draft, а не документ, принятый рабочей группой SIDROPS, и не стандарт IETF. - Проект прямо оставляет порядок и fallback между проверкой MOA и IPv6 ROA ожидаемой спецификации верификации. Минимальным общим контролем должна стать публичная матрица исходов двух плоскостей, при которой окончательная политика остаётся у оператора.
Один подписанный MOA может разрешать единственному IPv6 mapping prefix создавать отображение сразу для нескольких IPv4-префиксов. Кэш вправе передать длинный набор в нескольких сообщениях. Если позднее отзывается только часть, историческая разбивка пакетов не должна становиться условием правильного удаления.
Revision 01 устраняет такую зависимость. Полный отзыв можно отправить одним PDU со всеми прежними IPv4-префиксами либо несколькими PDU с прежними подмножествами. Для частичного отзыва объединение одного или нескольких Withdrawal PDU обязано содержать ровно отзываемые префиксы. Маршрутизатор удаляет это объединение из локальной базы MOV и не требует совпадения числа сообщений объявления и отзыва.
Смысл правила шире упаковки. Полномочие относится к связи префиксов, а не к тому, как однажды был нарезан транспорт. Новое разбиение не создаёт новое разрешение, а старое разбиение не сохраняет утраченное.
В revision 00 этого не было. Официальное сравнение показывает также каноническую сортировку, раздел о жизненном цикле и явную границу для комбинированной валидации.
Слово SIDROPS в имени не равно принятию рабочей группой
Карточка Datatracker и API документа относят текст к активным индивидуальным представлениям. Для него не указаны поток IETF, ответственный Area Director, shepherd или предполагаемый уровень стандарта. История фиксирует версию Guozhen Dong 9 сентября, а API представления — авторов и даты.
sidrops указывает на предмет и желаемое место обсуждения. Оно не сообщает о решении Working Group. Цитируемый MOA profile действительно является документом SIDROPS WG, но статус не переносится по ссылке. Запрошенное значение PDU у IANA по-прежнему обозначено как TBD; запрос не равен распределению.
Подпись, доставка и действие — не одно состояние
Первая сущность — MOA, подписанный держателем адресов. MOA profile revision 04 разрешает IPv6 mapping prefix быть источником отображений для одного или нескольких IPv4-префиксов. Для нескольких IPv6-префиксов нужны отдельные MOA. Объект выражает ограниченное полномочие, а не маршрут.
Вторая сущность — результат relying party. Он выполняет проверки подписанного объекта по RFC 6488, а затем убеждается, что каждый IPv4-префикс покрыт расширением IP-ресурсов EE-сертификата. Profile отдельно говорит, что PKI даёт authorization, но не аутентификацию личности и не non-repudiation.
Третья сущность — PDU, который кэш выводит из проверенного MOA и упорядочивает для маршрутизатора. Защищённый сеанс обеспечивает целостность доставки, но не превращает производную запись в исходный подписанный объект.
Четвёртая — локальная запись MOV. Согласно RFC 8210, Serial Number — логическая версия одного кэша. Серийные номера нельзя сопоставлять между кэшами или версиями протокола, и они не обязаны сохраняться после reset. Protocol Version, Session ID и Serial Number определяют сравнимость состояний, а не волю держателя ресурса.
Пятая — BGP-анонс 4map6. Revision 06 документа 4map6 проверяет достижимость mapping prefix, обновляет Mapping rule Database и описывает локальные ограничения распространения. Изменение RIB, FIB и пути пакетов остаётся следующим, отдельно наблюдаемым эффектом.
ROA нельзя использовать как синоним MOA. RFC 9582 описывает разрешение автономной системе анонсировать маршруты к префиксам. Предложенный MOA разрешает IPv6 mapping prefix создавать отображение IPv4-префиксов. Общая инфраструктура RPKI не делает эти действия одинаковыми.
Переданный отзыв и локальное истечение
Revision 01 применяет механизмы Refresh, Retry и Expire из RFC 8210. По истечении Refresh маршрутизатор отправляет Reset Query и должен продолжать пользоваться установленными данными MOA, пока ждёт ответ. После неудачи Retry задаёт повтор. Если успешного обновления нет до Expire, маршрутизатор обязан удалить все данные MOA и прекратить основанные на них решения MOV до восстановления связи.
Изменение данных MOA должно сопровождаться увеличением Serial Number. Так в пределах сравнимого сеанса обнаруживается старая или рассинхронизированная картина.
Withdrawal и Expire отвечают на разные события. Отзыв сообщает об изменении определённых полномочий. Истечение ограничивает локальное использование всей картины кэша, которую слишком долго не удаётся подтвердить. Частичный отзыв оставляет другие записи; Expire временно исключает весь вход MOA из решения.
Ни одно событие само по себе не доказывает удаление 4map6-маршрута из RIB или FIB и не подтверждает восстановление трафика. Подписанный объект, PDU, запись MOV, состояние BGP и измерение пакетов нужно хранить раздельно.
Спецификация заканчивается перед развилкой
MOA profile объясняет необходимость второй проверки. Правильное разрешение от держателя IPv4 не мешает третьей стороне злонамеренно анонсировать лежащий в основе IPv6-префикс. Поэтому profile рекомендует также IPv6 ROA validation.
PDU повторяет зависимость, но объявляет подробное взаимодействие, порядок проверки и fallback вне своего scope. По тексту их должна определить ожидаемая MOA verification specification, сопровождающая profile.
На момент исследования публичный поиск Datatracker по MOA в именах документов и Mapping Origin в заголовках находил profile, PDU и материалы заседаний, но не действующий документ с заявленной функцией проверки. Это вывод только о публичной записи. Он не доказывает отсутствие частной логики в коде и не исключает будущий draft.
Развилка возникает в нормальной эксплуатации. Что делать при MOA Valid и IPv6 ROA Invalid? Что означает NotFound: блокировку, снижение приоритета, отсутствие оценки или переход к профилю оператора? Если MOA-кэш ещё внутри окна Expire, но IPv6-маршрут изменился, чьё время наблюдения важнее? Какие тесты надо повторить после подключения перед восстановлением mapping?
Serial Number не ранжирует два вида авторизации. Он упорядочивает версии одного кэша в сравнимом контексте. Точный отзыв отвечает, что удалить, но не отвечает, чему верить.
Начальный scope 4map6 — контролируемая среда одного оператора или небольшой группы сотрудничающих операторов. Для расширения документ ожидает отдельный механизм аутентификации. Локальное соглашение может быть достаточным для такой группы, однако его нельзя молча выдавать за общий смысл протокола.
Минимальная матрица для двух плоскостей
Сам PDU расширять необязательно. Сопутствующая спецификация или публичный операторский profile могут дать матрицу исходов двух плоскостей.
Строка матрицы соединяет результат MOA и причину с endpoint кэша, Protocol Version, Session ID, Serial Number и временем наблюдения, а затем с результатом IPv6 ROA для mapping prefix. Далее она задаёт порядок проверок, блокировку или деградацию, неисполненную проверку, сохранённое или удалённое локальное состояние, версию политики, действие и условие восстановления.
Минимальные случаи: валидный MOA с IPv6 Valid, Invalid и NotFound; невалидный или истёкший MOA; старые данные до и после Expire; частичный и полный отзыв; reset; синхронизация после повторного подключения. NotFound не должен превращаться в Valid, а невыполненный тест — в успешный.
Такой подход соответствует Minimum Initial Specification Хэна Лу: общим становится только минимальный стык, необходимый для координации, а итоговая политика остаётся локальной. Running Code Primary добавляет требование сохранять доказательство реально сработавшего правила. Матрица — моё редакционное предложение, не требование IETF, SIDROPS или авторов.
Revision 01 правильно отделила отзыв полномочия от старой упаковки. Следующий текст должен столь же точно показать, как два результата проверки позволяют вернуть это полномочие в действие.
Источники
- IPv6 Mapping Prefix PDU, revision 01
- IPv6 Mapping Prefix PDU, revision 00
- Официальное сравнение 00–01
- Карточка PDU в Datatracker
- История Datatracker
- API документа Datatracker
- API представления revision 01
- MOA profile revision 04
- Карточка MOA profile в Datatracker
- 4map6 revision 06
- RFC 8210: RPKI-to-Router Protocol Version 1
- RFC 6488: RPKI Signed Object Template
- RFC 9582: Route Origin Authorizations
- Устав SIDROPS
- Heng Lu — Minimum Initial Specification
- Heng Lu — Running Code Primary
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров

