Кратко

  • Prop-164-v005 снизила бы минимальную IPv6 allocation с /32 до /40, разрешила меньшие блоки на nibble-границах и ввела возврат, уменьшение и резервирование.
  • Prop-170-v001 сохранила бы минимум /32 и выравнивала allocation лишь по просьбе заявителя после подтверждения потребности действующей процедурой.
  • Оценки воздействия от 18 августа требуют согласовать тексты, если оба получат консенсус. До APNIC 62 необходимо показать варианты только 164, только 170, оба и ни один.

Одно удобство не означает одну норму

Обзор NOG Alliance показывает prop-164 и prop-170 как два самостоятельных предложения для APNIC 62. Так их и следует оценивать.

Пятая версия prop-164 меняет входной порог. Она допускает allocation меньше /32, вплоть до /40, с четырёхбитными ступенями /32, /36 и /40. Некоторым нынешним держателям она позволяет вернуть излишек и сократить блок. Разреженное размещение или резерв по соседству должны оставить возможность дальнейшего роста.

Prop-170-v001 действует после входа. Сначала потребность проходит действующую оценку, затем по явной просьбе итог может быть выровнен по nibble-границе. Минимум /32 остаётся; assignments не входят в область; держатели обычно не обязаны возвращать пространство, менять размер или перенумеровываться.

Поэтому участник вправе поддержать условное выравнивание и отвергнуть новый порог /40. Другой вправе поддержать малые регистрируемые allocations, но не согласиться с механизмом расширения prop-170. Общая эстетика адресного плана не заменяет эти решения.

Эволюция prop-164 подчёркивает различие. Старая версия в Mail Archive описывала выбор между слишком крупной allocation и меньшим assignment, который не позволяет должным образом фиксировать sub-allocations. JPNIC разъяснила эту проблему японскому сообществу. Затем /36 сменился на /40, появились возврат и резерв. Изменился объём власти, а не только номер редакции.

Предупреждение 18 августа касается существа

Оценка prop-164 называет примерно девять месяцев: системы должны принять малые allocations, сокращение существующих блоков и резервы. Нужно уточнить, разрешено ли уменьшение /32 до /36 или лишь до /40, что делать без подходящего соседнего диапазона и достаточно ли нынешнего sparse allocation.

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

После этого оба документа отмечают: при консенсусе по двум предложениям понадобится правка, исключающая конфликт. Такое замечание не даёт редактору пустого мандата.

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

Даже прежние отзывы нельзя складывать в одну позицию. Японские участники спрашивали, не приведёт ли переход от /32 к /36 лишь к повторному спору о /40, и оспаривали эффект экономии. Материал SANOG фиксировал аргумент о точности Whois/RDAP. Оба свидетельства относятся к нижней границе prop-164, а не ко всему механизму prop-170.

Четыре строки до 10 сентября

Только prop-164: новая граница, допустимые ступени, условия возврата, резерв, отсутствие смежного места и положение нынешних держателей. Условное выравнивание prop-170 не добавляется по аналогии.

Только prop-170: /32 сохраняется. Просьба о выравнивании, подтверждённая потребность и итоговый prefix должны быть разными этапами; assignments остаются вне нормы; отсутствие смежного расширения получает явное правило. Вход /40 и возврат prop-164 не возникают.

Оба: нужен настоящий совмещённый текст. Какое определение главнее? Можно ли уменьшиться до /36, /40 или обоих значений? Является соседний резерв обязанностью, практикой по возможности или не является обещанием? Какая норма действует, если соседняя область занята? Обещание согласовать потом ничего не решает.

Ни один: сохраняется нынешняя линия. Отсутствие консенсуса не разрешает воспроизвести результат внутренней инструкцией.

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

Техническая польза не расширяет полномочия

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

Но роли остаются отдельными. Сообщество представляет факты и оценивает предложения. Председатели определяют консенсус по конкретной версии. Секретариат анализирует и внедряет принятую норму. Держатели проектируют и эксплуатируют сети. Whois и RDAP показывают делегирование, но не доказывают BGP-анонс, использование всего резерва или успех плана.

Подход Хэн Лу в Minimum Initial Specification даёт полезную границу: общая норма должна охватывать только необходимое для координации, а будущие решения оставаться у тех, кто их применяет. В данном случае надо точно назвать изменяемое состояние реестра и сохранить операционные решения за сетью.

Исход APNIC 62 неизвестен. Может появиться новая версия; шесть и девять месяцев — оценки; результат для реального заявителя и маршрутизации предсказывать нельзя.

Установлен более узкий факт: потенциальное противоречие обнаружено до встречи, но точное решение ещё не вынесено на публичное рассмотрение. Матрица четырёх исходов исправит порядок. Четыре бита делают адрес понятнее; документированная цепочка должна сделать понятнее полномочие.

Источники