Кратко

  • Предложение 2024-01 проходит Review Phase с 25 августа по 23 сентября 2026 года. Оно ещё не принято и не внедрено.
  • Предлагаемый раздел 2.6 не считал бы запрещённой субделегацией ограниченное использование префикса /56 или длиннее другой организацией в той же географической конечной точке.
  • Раздел 7.2 разрешает LIR использовать PI только для собственной инфраструктуры, не обслуживающей клиентские End Sites. Анализ воздействия RIPE NCC говорит, что после вступления конечного пользователя его прежние субделегации перестанут соответствовать этому разделу.
  • Нужна квитанция перехода: время активации LIR, оценки до и после, уведомление, путь исправления и итог — без публикации клиентов и топологии.

Сеть прежняя, правовой режим новый

Представим конечного пользователя с IPv6 PI. На той же площадке внутри его сети подключено клиентское устройство, которому выделен постоянный префикс в рамках предлагаемого исключения. Затем организация завершает приём в RIPE NCC: подписывает SSA, оплачивает счёт и получает активную учётную запись LIR.

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

Значит, событие комплаенса рождается не в пакетном потоке, а в институциональном статусе. Если последующая проверка сохранит только пометку «не соответствует», из истории исчезнет важный факт: до активации LIR тот же способ использования оценивался по другому критерию.

Это не довод против членства. Это довод за точное датирование смены режима.

Раздел 2.6 создаёт узкое исключение

Проект документа сохраняет общий запрет полностью или частично передавать назначенный адресный ресурс другой организации. Но он выводит из понятия субделегации один класс ситуаций: подключение другой организации внутри сети держателя, в той же географической конечной точке, с префиксом /56 или длиннее. Среди примеров — постоянная адресация сервера или устройства и отдельные соединения между операторами.

Это не разрешение обслуживать удалённые клиентские сети. Важны место, контроль сети, длина префикса и задача маршрутизации. Анализ RIPE NCC отдельно замечает, что «географическая конечная точка» определена недостаточно строго: зданием, адресом, городом или страной.

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

Раздел 7.2 проверяет держателя как LIR

Действующая политика ripe-738 запрещает дальнейшую субделегацию PI другим организациям. По разделу 7.2 LIR может получить IPv6 PI для частей собственной инфраструктуры, не используемых для клиентских End Sites. Если исходные условия перестали действовать, LIR следует вернуть назначение в течение шести месяцев.

Между новым исключением 2.6 и специальным правилом 7.2 в 2024-01 пока нет завершённого перехода. RIPE NCC формулирует коллизию буквально: конечным пользователям позволят некоторые субделегации из PI; если затем такой пользователь станет членом, они перестанут быть допустимыми.

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

Страница о вступлении в RIPE NCC даёт наблюдаемую границу. После получения оплаты и подписанного SSA RIPE NCC активирует учётную запись LIR. Именно это время лучше отделяет два состояния, чем расплывчатая дата подачи заявления.

Спонсорский LIR не равен собственному статусу LIR

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

Сегодняшняя инструкция по IPv6 PI также проводит практическую черту. Клиентский сервер или устройство можно подключить с отдельным адресом, но нельзя передать другой организации префикс — даже /64 или /96. Проект сдвигает эту черту для совместной площадки, а последующее членство может сдвинуть её обратно.

Поэтому одной записи inet6num или снимка маршрутов недостаточно. В технических данных нет обязательного поля с моментом, когда организация стала LIR.

Квитанция должна соединить две проверки

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

Ключевое поле — membership_lir_effective_at, время активации учётной записи. Перед ним сохраняется оценка по 2.6, после него — оценка по 7.2. У каждой есть ответственный, категория доказательств и список нерешённых условий.

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

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

Текст всё ещё обсуждается

На странице текущих предложений Review Phase для 2024-01 заканчивается 23 сентября. В обсуждении Address Policy Working Group противоречие между 2.6 и 7.2 уже отмечено участниками. После обсуждения сопредседатели оценят наличие rough consensus.

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

Источники