Кратко

  • Draft 2 сохраняет порог 90% и предлагает исключение для доказанных ключевых технических целей.
  • В досье нужны топология, обоснование размера префикса, расчёт использования, альтернативы и проверки на мошенничество.
  • Приблизительный консенсус AFRINIC 37 и статус Last call не являются ратификацией Board или внедрением.

Примечание о публикации: «Опубликовано» означает запланированную редакционную дату 7 сентября 2026 года. Фактическое время публикации на сервере не установлено.

Действующий CPM, раздел 5.4.6.1, требует от LIR или конечного пользователя, запрашивающего дополнительное распределение или назначение IPv4 в фазе исчерпания, использовать не менее 90% всех прежних ресурсов. Первый запрос нового LIR или конечного пользователя без прежних ресурсов является исключением.

AFPUB-2026-IPv4-002-DRAFT02 от 16 июня 2026 года, после первой редакции от 6 мая, сохраняет эту основу. Он предлагает разрешить AFRINIC отступить от порога, если доказанная ключевая техническая цель практически не может быть обслужена существующим пулом оператора или создаёт для него технические ограничения. Неисчерпывающие примеры — резервирование и высокая доступность, механизмы перехода IPv6 и расширение на новые площадки. Обоснование должно быть достаточно документировано для проверки соответствия, но проект не задаёт публичную схему доказательств, минимальный пакет документов, запись решения по делу или требование публикации.

Это важно для равного отношения, защиты от мошенничества и аудируемых решений hostmaster. Примеры расширения дата-центра и ISP с несколькими точками присутствия BGP, использующего 464XLAT и NAT64, принадлежат автору предложения; они не подтверждают соответствие конкретного участника. Утверждение примерно о трёх миллионах возвращённых IPv4-адресов, снижающих немедленный риск для пула, также является приписанным политическим аргументом, а не независимым измерением запасов в этом материале.

Сотрудники AFRINIC считают 90% базовым условием, а исключение — допустимым только для технических, не операционных ограничений. Они указывают на необходимость документированной политики для hostmaster и процедур, выявляющих мошеннические запросы и предотвращающих злоупотребление. Процедуры и FAQ Member Services потребуют обновления; изменений в WHOIS, RDAP, MyAFRINIC, NetSuite, NMRP или RPKI не выявлено. Оценка внедрения в течение 30 дней после ратификации остаётся планом, а не доказательством ратификации или внедрения.

На AFRINIC 37 24 июня 2026 года обсуждались трудности достижения 90% на нескольких площадках и различие между эффективным использованием и операционной топологией. Формальное решение председателей зафиксировало приблизительный консенсус и объявило, что Секретариат представит определение использования во время Last Call. В открытом микрофоне сначала прозвучало, что предложение не прошло, но сопредседатель PDWG уточнил, что приблизительный консенсус был достигнут. На момент заморозки отчёта страница предложений обозначает статус как Last call. Это отдельная стадия от последующей рекомендации Board, ратификации и внедрения.

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