Кратко

  • В версии 2 широкую переоценку убрали сознательно; автор предложения позднее уточнил, что при неизменной потребности для существующего владельца последствий нет.
  • Рост включает путь к следующей nibble-границе. Если смежного пространства недостаточно, возможны новая выдача и возврат прежних назначений в течение шести месяцев.
  • Четырнадцатипольная квитанция и пять тестовых векторов способны закрепить переход, оставив топологию, клиентов, подробные доказательства потребности и план работ локальными или закрытыми.

Девять строк до появления нового факта

В марте 2025 года участник обсуждения сообщил, что его сеть располагает девятью разными PI-назначениями /48 и хотела бы объединить их, желательно без перенумерации. Он отдельно упомянул объекты базы и DNS.

Это заявление конкретного участника, а не независимая проверка актуального владения и не оценка числа подобных сетей. Из девяти /48 нельзя выводить злоупотребление, расточительство или нарушение.

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

Отсутствие роста означает отсутствие вмешательства

В объявлении версии 2 от октября 2025 года прямо перечислено, что убрали из версии 1: предлагаемое определение End Site и переоценку потребности при запросе дополнительного или более крупного назначения. Текст хотели сделать короче и понятнее. Это не случайный пробел.

Когда в марте 2026 года прозвучал вопрос о владельцах нескольких PI без увеличения потребности, автор предложения ответил, что при неизменной потребности для них нет последствий.

Такой предел полезен. Новая модель политики не должна превращать корректно работающую сеть в обязательный миграционный проект ради единообразия записей. Реестр координирует номера, но не распоряжается локальным графиком DNS, ACL, маршрутизаторов и приложений.

Следовательно, исправлять нужно не покой старого состояния, а наблюдаемость события, которое выводит его из покоя.

Один запрос меняет режим

Обсуждаемая формулировка раздела 7.1.2 ведёт владельца одной или нескольких PI с новой потребностью к расширению до следующей nibble-границы. Если смежное расширение невозможно, он может получить новое назначение и должен вернуть прежнее или прежние в течение шестимесячного периода перенумерации. Один из участников процитировал эту ветвь и оспорил срок, предложив двенадцать или 24 месяца либо обоснованное продление.

Эта статья не выбирает срок. Она не сообщает о пропущенной дате, сбое или реальном решении. Доказуема только структура:

старый набор → новая потребность → проверка смежности → расширение или замена → совместная работа → возврат.

Итоговый префикс не сохраняет сам по себе номер запроса, версию текста, состав старого набора, снимок резерва, начало периода, список возврата и последующие исправления.

Проект ещё не стал действующей политикой

15 июня 2026 года сопредседатели сообщили о восьми сторонниках и намерении перейти к Review Phase. Они обещали учесть небольшие редакционные изменения и опубликовать проект политики с анализом воздействия.

Это подтверждает намерение, а не открытие этапа, консенсус, принятие или внедрение. Из рассмотренного независимого архива нельзя сделать более сильный вывод.

Такое положение даёт возможность определить квитанцию до первого рабочего случая. Иначе скрытая практика обработки заявок постепенно станет фактической спецификацией без проверяемых тестов.

Перенумерация проходит через двойное состояние

RFC 4192 описывает перенумерацию IPv6 без одномоментного переключения: подготовить новый префикс, добавить адреса, поэтапно изменить маршрутизацию, DNS, DHCP и статические ссылки, дать старому и новому состояниям поработать вместе, проверить новое и лишь затем убрать старое.

RFC 5887 показывает оставшиеся трудности. Статические адреса рассеяны; часть зависимостей обнаруживается только после жалобы пользователя. Во время наложения правила и мониторинг обязаны видеть оба набора, а инструменты не всегда умеют работать с несколькими префиксами.

RFC не устанавливают правила RIPE и не определяют шесть месяцев. Они доказывают более узкое: решение реестра и миграция сети связаны, но принадлежат разным владельцам. Общий документ должен связать факты, не централизуя исполнение.

Порог как объект аудита

Пусть P0 — упорядоченный старый набор PI на точный момент, N0 — прежняя документированная потребность, q — новый запрос, H — применённый текст. C(q, P0) обозначает результат проверки резерва и смежности, T — выбранную ветвь, P1 — итоговый ресурс, D — наложение, срок и закрытие.

Тогда переход:

E = G(P0, N0, q, H, C, T, P1, D).

Это аналитическая модель Theo March, а не опубликованная схема RIPE NCC. До q набор P0 остаётся неизменным. После q запрос, доказательства, решение, старое и новое состояния должны сохраняться вместе.

Четырнадцать полей квитанции

  1. Идентичность. Стабильный ID квитанции и версия схемы.
  2. Применённое правило. Номер предложения или политики, версия, достоверный дайджест, статус и дата действия.
  3. Срез прошлого состояния. Точное время и часовой пояс исходного набора.
  4. Владелец и запрос. Безопасная публичная ссылка, ID дела и подтверждённое время подачи, без личных контактов.
  5. Класс триггера. Запрос без изменения, дополнительное пространство, более крупное назначение или исправление; причина применения или неприменения 7.1.2.
  6. Старый набор PI. Упорядоченные идентичности, длины, статусы и дайджесты записей.
  7. Оценённая потребность. Одобрена, отклонена или не определена, целевая единица и ограниченный код причины; исходная топология может быть закрыта.
  8. Nibble-цель. Запрошенная и оценённая граница с причиной расхождения.
  9. Доказательство смежности. Идентичность снимка резерва, проверенный соседний диапазон, время и детерминированный результат без раскрытия чужих ресурсов.
  10. Выбранный путь. Расширить, заменить, оставить, отклонить или запросить доказательства.
  11. Итоговый ресурс. Идентичность, префикс, версия объекта и время активации.
  12. Часы совместной работы. Начало, дата возврата, часовой пояс и идентичность разрешённой паузы или отсрочки.
  13. Набор возврата и закрытие. Состояние каждого старого назначения, доказательство завершения и нерешённое исключение.
  14. Цепочка исправлений. Орган решения, путь пересмотра, заменённая квитанция и конечный статус.

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

Пять тестов до внедрения

  1. Несколько старых PI без роста. Триггера и срока возврата нет.
  2. Смежное расширение. Старый набор, снимок резерва и расширенный объект связаны.
  3. Несмежная замена. Новое назначение, явный набор возврата и период наложения.
  4. Отозванный до активации запрос. Дело закрыто, часы возврата не запущены.
  5. Исправление состава или времени. Добавляется новая квитанция со ссылкой на прежнюю, история не перезаписывается.

Разные системы могут реализовать логику по-разному. Совпадать должна минимальная семантика результата.

Общий слой должен закончиться рано

HENG.LU Note 64 предлагает стандартизовать лишь необходимое для идентичности, совместимости и общей безопасности. Здесь это старые и новые ресурсы, версия правила, триггер, смежность, ветвь, часы, закрытие и исправление.

Топология, трафик, клиенты, подробные данные использования, оборудование, коммерческая цель и порядок работ остаются локальными или защищёнными. Сообщество задаёт правило; RIPE NCC применяет и удостоверяет своё решение; владелец сообщает факты и управляет сетью; наблюдатель проверяет, но не получает права выдавать, маршрутизировать или аннулировать.

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

Источники

Границы доказательств

Проверено: версия 2 убрала широкую переоценку; неизменная потребность не затрагивается; обсуждаемый текст содержит ветвь роста и шесть месяцев; сопредседатели собирались двигаться дальше; IPv6-перенумерация имеет перекрывающиеся состояния.

Вывод: итоговая запись не восстанавливает триггер, смежность, набор возврата и часы.

Рекомендация: квитанция из четырнадцати полей и пять тестовых векторов до внедрения.

Неизвестно: Review-текст, анализ воздействия, окончательный срок, старт часов, исключения, внутренняя схема дел, число владельцев и производственное внедрение.