Кратко

  • В прежнем тексте один сайт занимал 100% блоков /48 внутри одного /48, поэтому правило 75% буквально переводило заявку на следующую nibble-границу — /44. Но пример начинал /44 только с двух сайтов.
  • Рекомендуемый проект сначала закрепляет /48, а затем задаёт интервалы 2–12 → /44, 13–192 → /40, 193–3 072 → /36 и 3 073–49 152 → /32. Это всё ещё Recommended Draft Policy, а не доказанно принятая или внедрённая норма.
  • Исправление не превращает /48 в закон протокола. Оно требует, чтобы нормативная фраза, пример, тест реализации и цепочка исправлений давали один версионированный результат.

Пример временно стал нормой

В одном /48 содержится один учитываемый /48. При одном сайте отношение равно 1/1, то есть 100%. Прежняя фраза раздела 6.5.8.2 направляла организацию к следующей большей nibble-границе, если число сайтов превышало 75% доступных /48. Буквальный ответ — /44.

Следующая строка примера относила к /44 больше одного, но не более двенадцати сайтов. Один сайт оставался на /48.

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

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

Что исправил Recommended Draft

Независимая копия июньского сообщения сохраняет полный рекомендуемый текст. Организация, прошедшая одно из начальных условий, получает право на /48. Большие размеры определяются отдельной таблицей: 2–12 сайтов — /44, 13–192 — /40, 193–3 072 — /36, 3 073–49 152 — /32.

Одновременно assignment заменяется на allocation. Приведённая оценка Консультативного совета говорит, что терминология соответствует текущей процедуре, а уточнение отражает действующую практику и не меняет работу реестра.

Это утверждение института, а не внешне воспроизведённая статистика. В наборе источников нет обезличенной выборки решений, исторического распределения размеров или теста реализации. Поэтому нельзя говорить, что реальный заявитель получил ошибочный блок, столкнулся с задержкой или разным обращением. Нельзя и объявлять отсутствие изменений независимо проверенным.

Обзор NOG Alliance показывает статус Recommended Draft Policy. Он подтверждает продвижение текста, но не принятие, вступление в силу или изменение производственной системы.

/48 — выбор политики, а не константа IPv6

После ремонта таблица выглядит естественной. RFC 6177 объясняет, почему естественность не равна обязательности. Документ отказался от единого /48 по умолчанию для большинства конечных сайтов: разнообразие сетей требует более тонкого подхода. IETF даёт архитектурные и эксплуатационные ориентиры, а точный размер выбирает операционное сообщество.

RFC также предостерегает от жёсткой фиксации нескольких длин так, будто IPv6 стал классовой адресацией. CIDR сохраняется.

Это не опровергает выбор /48 для описанной категории. Это определяет его природу: публичное институциональное решение, которому нужны версия, границы применения и исправление. Протокол не выдаёт числу 48 самостоятельную власть.

Реестр может определить размер по опубликованному правилу. Топология, подсети, рост и услуги остаются под контролем оператора. Запись префикса не создаёт общего права проектировать сеть.

Один пробел — много частных расходов

Внешний разбор IPv4 Global программы ARIN 57 называет поправку небольшой и ожидает меньше переписки для малых конечных пользователей. Это прогноз коммерческого аналитика, а не измерение после внедрения. Но механизм затрат понятен.

Внутренняя команда один раз формирует толкование и применяет его повторно. Каждый новый заявитель открывает это толкование снаружи. Большая организация может нанять специалиста; односайтовая — потратить время собственной небольшой команды.

Цена возникает не из четырёх битов, а из неопределённой иерархии документов. Что выше: фраза, таблица, справка или внутренний обычай? Хорошая политика отвечает до частной переписки.

Малое отражение Policy Mirror

Lu Heng пишет в The Policy Mirror, что руководство отражает представление института о собственных полномочиях. Узкий реестр защищает уникальность, точность, доказуемый контроль, безопасность и непрерывность. Граница смещается, когда административная практика без записи начинает управлять более широкими решениями оператора.

ARIN-2025-7 не требует громкого обвинения. Малый случай показывает точный механизм: законная функция выбора размера получила два публичных исполнения. Пример нёс предполагаемый ответ, а практика окончательно разрешала расхождение.

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

Таблица паритета без раскрытия заявки

Для существенной версии достаточно восьми полей:

Поле Минимальное содержание
Идентичность текста Номер, дата, хеш и стадия процесса.
Класс входа Право, обычные сайты, особая потребность или исправление.
Буквальный выход Префикс только по нормативной фразе.
Выход примера Префикс по опубликованной таблице.
Практический выход Применяемый класс в тесте или агрегате.
Разрешение разницы Нет разницы, исправлен текст, пример, практика или пересмотрено дело.
Ограниченная причина База одного сайта, многосайтовый порог или особая потребность.
Пересмотр Орган, дата, заменяющая версия и путь возражения.

Это аналитическая модель статьи, а не заявленная схема ARIN. Она не требует раскрывать топологию.

Четыре теста обнаруживают дефект: 1 сайт возвращает /48, 2 — /44, 12 остаются на /44, 13 переходят на /40. Фраза, пример и реализация должны запускаться с одним хешем текста. Для особо крупного сайта нужен отдельный вектор.

Та же система защищает будущие редакционные правки. Замена термина не меняет выход. Намеренная смена границы видна как одобренная разница.

Признать ремонт, не придумывая ущерб

Доказано существование противоречия и ясного исправления в Recommended Draft. Не доказаны принятие, внедрение, ущерб, ошибочное решение или операционное изменение. Историческая единообразность практики тоже не воспроизведена независимо.

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

Некоторое время односайтовый /48 держался на примере. Теперь эту работу должен выполнять сам нормативный текст.

Источники

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

Проверено: буквальное противоречие для одного сайта; явные интервалы рекомендуемого текста; приписанное Совету заявление о непрерывности; Recommended-статус в независимом обзоре; отказ RFC 6177 от универсального /48.

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