Кратко

  • В действующем APNIC-127 минимальная IPv4-делегация равна /24, а максимальный совокупный объём из 103/8 — /23. При этом критерий для первоначального LIR требует немедленной потребности в /24 и подробного плана использования как минимум /23 в течение года.
  • Prop-169, вынесенный на обсуждение APNIC 62, заменяет фиксированный /23 на «оцениваемую IPv4-делегацию». Опубликованные границы сохраняют проверку потребности, принцип conservation и действующие лимиты, не создают нового права и не открывают заново более широкие вопросы делегаций, трансферов или листа ожидания.
  • Новая фраза должна различать запрошенный, оценённый и окончательно делегированный префиксы. Защищённая версионная запись позволит связать эти значения, не публикуя сведения о клиентах и не превращая проверку потребности в проектирование чужой сети.

Один бит, две роли и пропущенная связь

Префикс /23 содержит 512 IPv4-адресов. Префикс /24 — 256. Разница в один бит удваивает или сокращает вдвое доступное множество. С арифметикой проблемы нет. Проблема появляется, когда один размер означает минимально допустимую выдачу, другой — максимальную, а в критерии будущего использования они ведут себя так, будто речь всегда идёт об одном и том же объёме.

Действующие правила APNIC об интернет-ресурсах нумерации в разделе 6.1 устанавливают /24 как минимальную делегацию и /23 как максимальный совокупный объём, который владелец учётной записи может получить из 103/8. Раздел 6.2.1 требует от первоначального LIR уже использовать /24 от вышестоящего провайдера либо доказать немедленную потребность в таком блоке. Затем он требует подробный план использования не менее /23 в течение одного года.

Если рассматривается /23, две части могут совпасть. Если сеть просит /24, годовой ориентир оказывается вдвое больше самой заявки. Прогноз роста за пределы первой делегации может быть разумным доказательством. Но тогда правило должно прямо сказать, что проверяет именно рост. Иначе заявитель не понимает, является ли /23 будущим правом, обязательным порогом, верхней границей или случайно сохранившейся цифрой.

Текстовый файл APNIC-127 позволяет зафиксировать нормативный снимок без пересказа. Он называет себя активной версией 015 от 20 февраля 2025 года. В нём остаются минимум /24, максимум /23 и годовой план /23. Текста prop-169 в действующей версии ещё нет.

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

Удалить фиксированное число — правильное начало

Публичная копия prop-169 в списке Policy SIG описывает узкую замену. Вместо плана использования не менее /23 первоначальный LIR должен будет представить подробный план использования оцениваемой IPv4-делегации в течение года. Ограничения APNIC-127 сохраняются.

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

Но это пока предложение. Версия 1 была направлена в список Policy SIG 13 июля 2026 года и должна обсуждаться на Open Policy Meeting APNIC 62. Обсуждение, консенсус, период финальных комментариев, одобрение, редакционная публикация и рабочее применение — разные события.

Архивный текст сознательно удерживает узкие границы. Он предусматривает пересмотр заметок для оценки, инструкций и материалов заявителей, где ещё упомянут фиксированный /23. Оценка потребности, принцип conservation и действующие лимиты сохраняются; нового права не возникает, а широкие вопросы делегаций, трансферов и листа ожидания не открываются заново.

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

Нейтральный трекер NOG Alliance помечает prop-169 как «To be discussed at APNIC 62». Это будущий этап встречи, а не результат. Пример с /24 показывает дефект формулировки; остальные вопросы политики IPv4 остаются за пределами этой правки.

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

Грамматическая определённость не создаёт идентификатор

В английском выражении “the delegation being assessed” есть определённый артикль. В транзакции определённость появляется не от артикля, а от значения, версии и времени фиксации.

Первое значение — запрошенный префикс: то, что заявитель указал при подаче или в явно отмеченной редакции. Второе — оценённый префикс: объём, относительно которого проверяющий рассматривает годовой план. Третье — делегированный префикс: результат, который APNIC или NIR вносит в реестр.

В обычной заявке все три могут быть /24. Это аргумент в пользу отдельных полей, а не против них. Запись same-as-requested делает обычный путь дешёвым и одновременно снимает сомнение, что одно из значений потерялось.

Если значения расходятся, различие становится критичным. Заявитель может начать с /23, а доказательства могут поддержать /24. Он может изменить запрос после уточняющих вопросов. Расчёт остающегося права может ограничить итог. Публичные источники данного пакета не показывают, что такие переходы происходят в нынешней практике. Вывод уже: предложенная публичная фраза их не исключает, но не называет запись перехода.

Рядом существует четвёртое число — остающееся право на ресурсы. Оно вычисляется из применимого максимума и релевантных текущих владений. Это число может ограничивать решение, но не должно выдаваться ни за исходную волю заявителя, ни за профессиональный вывод проверяющего.

Соседний критерий показывает более явную грамматику. Раздел 6.2.2 требует от заявителя по пути multihoming доказать немедленное использование 25 процентов и годовое использование 50 процентов именно запрошенных адресов. Это отдельная категория допуска, и её проценты нельзя незаметно перенести на первоначальный LIR. Однако сама конструкция показывает, что APNIC-127 умеет привязывать тест к названной величине.

Prop-169 не должен копировать проценты. Ему достаточно так же точно определить объект оценки.

Три временных горизонта требуют явного знаменателя

Раздел 5.2.1 просит документированные оценки немедленной потребности, потребности через год и через два года. В качестве общего ориентира названы 25 процентов немедленно и 50 процентов в течение года. Если конечный пользователь не может уверенно оценить двухлетнюю потребность, APNIC или NIR может делегировать объём, достаточный только на один год.

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

Устойчивая запись должна показывать, какой горизонт определил какой размер. Без этого «оцениваемая делегация» может означать значение при подаче, значение после проверки немедленного использования или значение после того, как проверяющий ограничил вес двухлетнего прогноза.

Правила последующих делегаций дают полезный процедурный ориентир. Раздел 7 связывает решение с подтверждённым прошлым использованием, документированными планами и соблюдением политики и допускает покрытие потребности на срок до года. Если APNIC или NIR выбирает более короткий период, LIR должен узнать и период, и причины. Когда переменный результат сужается, правило уже требует назвать сужение. Для размера нужен тот же принцип.

Публичный максимум не заменяет защищённую историю решения

Страница APNIC о работе после исчерпания IPv4 сообщает участникам понятную границу. Совокупный максимум из 103/8 равен /23. Достигший максимума участник не может получить у APNIC больше, а участник ниже максимума может подать заявку через MyAPNIC. Тем, кому нужно больше /23, предлагается рассмотреть трансферы.

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

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

Максимум изменился, минимум остался

История двух размеров документирована. Интернет-хронология JPNIC отмечает консенсус по prop-127 на APNIC 47 и последующее вступление правила в силу; затем JPNIC прекратил максимальные выдачи /22 из возвращённого запаса и согласовал этот канал с /23. Нынешний минимум /24 подтверждает архив действующей политики, а не эта хронология.

Этот факт не доказывает субъективный замысел авторов каждой сохранившейся строки. Он объясняет структуру нынешнего интервала: допустимый запрос может находиться между двумя размерами. Фиксированный годовой /23 легко принять за естественное продолжение максимума, хотя доступный минимум никуда не исчез.

Позднее обсуждение двигалось к ещё меньшему максимуму. Prop-152 предлагал после исчерпания тогдашнего пула установить /24 в качестве максимума и ограничить последующие делегации новыми владельцами учётных записей. Консенсуса не было; в феврале 2024 года предложение забросили. Оно не является текущей политикой.

Тем не менее оценка prop-152 содержит полезный принцип проектирования. Секретариат предупреждал, что меняющиеся цифры доступного пула не следует встраивать в долгоживущий текст политики: во время обсуждения они успеют измениться. Лучше назвать переменную и источник. Но переменная становится устойчивой не просто после удаления числа. Ей ещё нужны референт, версия и момент связывания.

Минимальная защищённая запись о размере

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

Для начальной спецификации достаточно шестнадцати полей.

  1. Идентификатор и время заявки. Стабильный ключ, время подачи и явная связь с каждой редакцией или заменившей её подачей.
  2. Идентификатор правила. Версия APNIC-127, точный пункт, дата вступления в силу и использованная версия внедрения принятого предложения.
  3. Орган принятия решения. APNIC либо конкретный NIR, роль проверяющего и канал делегации; ответственность не должна скрываться за безличным названием системы.
  4. Класс заявителя и путь допуска. Первоначальный LIR, multihoming, критическая инфраструктура, IXP или другой разрешённый путь, чтобы критерии не переходили между классами молча.
  5. Текущие релевантные владения. Ресурсы из 103/8, иное учитываемое пространство и расчёт остающегося права с областью применения каждого входного значения.
  6. Запрошенный префикс. Точная длина, число адресов и объявленная заявителем редакция; /23 и 512 — две машинно проверяемые формы одного значения.
  7. Основание немедленной потребности. Размер и операционная функция связаны с защищёнными ссылками на доказательства, но одна предпочитаемая схема сети не становится правилом.
  8. Знаменатель годового плана. Точный префикс и число адресов, относительно которых оценивается прогноз. Именно это поле даёт существительное новой фразе prop-169.
  9. Статус двухлетнего прогноза. Представлен, не поддаётся уверенной оценке или неприменим — вместе с пунктом правил, допускающим этот статус.
  10. Хранение доказательств. Идентификаторы и хэши документов, класс доступа, срок хранения, режим конфиденциальности и исправления без публикации данных клиентов.
  11. Оценённый префикс. Точная величина, время превращения в знаменатель решения и правило, позволяющее такой выбор.
  12. Код различия. При расхождении с запросом — ограниченная причина, связанная с фактом; при совпадении — явное same-as-requested.
  13. История вопросов и ответов. Существенные вопросы, ответы и время, а также поле, изменившееся после каждого обмена.
  14. Окончательно делегированный префикс. Связь конечного размера с событием реестра, префиксом и временем; отличие от оценённого значения сохраняется.
  15. Исход и путь исправления. Выдано, выдано частично, отказано, отозвано или ожидает решения — с причинами, пересмотром и последующими коррекциями.
  16. Безопасная для приватности агрегированная проекция. Счётчики путей от запроса к оценке и выдаче, диапазоны времени обработки, причины различий, отзывы и исправления без идентификации заявителей.

Хэш защищённого документа не публикует его содержание. Для общего счётчика не нужно имя сети. Код remaining-entitlement-limit не раскрывает клиентов. Приватность и повторяемость совместимы, если общая часть ограничена необходимыми фактами.

Реестр фиксирует факты, а не проектирует сеть

Minimum Initial Specification задаёт полезную границу. Общий слой должен точно фиксировать минимум фактов, без которых совместная координация ломается. Будущие операционные решения остаются у тех, кто управляет сетью.

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

Такая граница дисциплинирует обе стороны. Заявитель не может прикрыть отсутствие проверяемого прогноза словами «будущий рост». Проверяющий не может истолковать требование подробности как неограниченный доступ к частным данным. Каждый вопрос связан с правилом и величиной, каждый результат — с теми же полями.

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

Публичная норма может быть узкой. Запись решения должна быть точной.

Источники

Чего источники не показывают

Ни один источник в этом пакете не сообщает, что APNIC или NIR отказал в конкретной заявке, задержал её либо уменьшил объём именно из-за фиксированной формулировки /23. Нет публичного массива, связывающего запрошенные, оценённые и делегированные размеры. Не опубликованы и действующие внутренние формы или заметки проверяющих. Поэтому статья выявляет текстовую и учётную неоднозначность, но не приписывает реестру доказанную практику нарушений.

Источники также не предсказывают решение APNIC 62. На дату снимка обсуждение ещё не состоялось. Новая версия может точнее связать размер, оставить прежний текст или изменить охват предложения. Каждый вариант будет новой фактической стадией, а не подтверждением сегодняшнего прогноза.