Кратко

  • RFC 7710 назначила DHCPv4-опцию 160 для обнаружения captive portal. Во время сетевого эксперимента IETF 106 выяснилось, что некоторые устройства Polycom уже применяли этот код иначе и после получения URL стандартизованного API работали не так, как требовалось.
  • RFC 8910 перенесла функцию на 114. IANA теперь помечает 160 как неназначенный, но сохраняет предупреждение о прежнем стандарте и использовании Polycom: статус реестра не доказывает, что ни одна установленная программа не реагирует на число.

Проверка началась с обычного пакета

На встрече IETF 106 в Сингапуре сеть участвовала в эксперименте с Captive Portal API. Совместимые клиенты должны были находить venue-info-url. Для DHCPv4 существовал официальный механизм: опубликованная в 2015 году RFC 7710 использовала код опции 160.

Когда сеть отправила этот код, его получили и некоторые устройства Polycom. Приложение B RFC 8910 сообщает, что они использовали 160 в иных целях. URL Captive Portal API в этой опции привел к тому, что устройства функционировали не так, как ожидалось.

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

Erik Kline написал RFC 8910 вместе с Warren Kumari. Предыдущую RFC 7710 подготовили Kumari, Olafur Gudmundsson, Paul Ebersman и Steve Sheng. Это коллективная работа по сопровождению протокола. Значение роли Kline здесь в том, что новый документ сохранил отрицательный результат, не превращая его в широкое обвинение.

Реестр определяет норму, прошивка — реакцию

Код DHCPv4-опции занимает один октет. Общий реестр IANA дает серверу и клиенту согласованное значение. Он отвечает на нормативный вопрос: какое применение признано стандартом. Без такой таблицы ограниченное пространство быстро распалось бы на несовместимые частные диалекты.

Но устройство не обращается к сайту IANA при разборе каждого ACK. Оно выполняет встроенную ветвь программы. Один клиент видит в 160 URI, другой может ожидать другую структуру и перейти в иное состояние. Пакет остается корректным для RFC 7710, однако становится неожиданным вводом для ранее выпущенного декодера.

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

RFC 3679 уже применяла этот принцип при возврате неиспользуемых DHCP-кодов. Одни значения освобождались, потому что проекты не стали стандартами и не вошли в общее употребление. Другие оставались зарезервированными: устройства применяли их без опубликованной RFC. Отсутствие формальной спецификации не принималось за отсутствие реализации.

Новый адрес — 114, а у 160 осталась биография

RFC 8910 вышла в сентябре 2020 года в потоке стандартов, заменила RFC 7710 и обновила RFC 3679. Для DHCPv4 она выбрала код 114. Нынешний реестр параметров BOOTP и DHCP IANA связывает 114 с DHCP Captive-Portal и RFC 8910.

Значение 160 отмечено как Unassigned. Однако в описании указано: прежде его назначала RFC 7710, а также известно об использовании Polycom. Метка описывает текущую формальную запись. Историческая оговорка не позволяет прочитать ее как обещание, что все прошивки игнорируют 160.

Перенос относился только к DHCPv4. В DHCPv6 опция captive portal осталась под номером 103, в IPv6 Router Advertisement — 37. Это разные пространства. Без уточнения «DHCPv4» формула 160→114 создает ложное впечатление, будто менялись все три.

Публикация нового кода не обновила старые устройства. Серверы должны начать отправлять 114, реле и системы контроля доступа — пропускать его, а клиенты — понимать. В переходный период рядом существуют клиенты 114, старые устройства с реакцией на 160 и системы без поддержки CAPPORT. Отправка обоих кодов может снова задеть уязвимую к 160 группу.

Успешный lease еще не означает успешный сервис

Развертывание следует начинать с перечня аппаратных семейств, прошивок и функций. В лаборатории воспроизводятся точный код, длина и типичная полезная нагрузка. Затем ограниченная canary-сеть проверяет намеренно смешанную выборку.

Нужно измерять получение адреса и продление аренды, но идти дальше: завершился ли запуск, зарегистрировался ли сервис, работает ли основная функция устройства. Терминал может успешно пройти DHCP и сломаться позже. Зеленая статистика ACK не опровергнет такой результат.

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

Отрицательный результат поддерживает общий стандарт

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

Надежный процесс соединяет полномочие и эксперимент. IANA фиксирует признанное значение. Ограниченная проверка выясняет, разделяют ли его наблюдаемые реализации. Если предположение о свободности неверно, стандарт может сохранить функцию и заменить средство.

RFC 8910 называет место, ограниченную группу устройств, общий эффект и принятое решение. Такая сдержанность важна: она не приписывает производителю неизвестную причину и все же оставляет следующему разработчику практическое предупреждение. История 160 стала частью качества 114.

Источники