Кратко

  • RFC 3679 отделил номера предлагаемых опций, которые можно вернуть, от кодов PXE и Apple, уже находившихся в употреблении без описания в опубликованном RFC.
  • RFC 3942 установил переходный порядок для кодов из частного диапазона. Позднее RFC 8910 перенёс сигнал captive portal с кода 160 после того, как эксперимент выявил конкурирующее использование Polycom. Реестр отражает координацию, а не перепись развёрнутых устройств.

Пустая библиография не означала пустую сеть

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

В январе 2004 года RFC 3679 рассмотрел обе стороны проблемы. В нём перечислялись прежние назначения, предложения по которым истекли, не дошли до опубликованного определения или больше не использовались тогдашним протоколом переключения. Эти коды можно было вернуть в доступный пул IANA. Но в отдельном разделе отмечалось, что опции PXE 93, 94 и 97 широко используются, хотя не описаны в опубликованном RFC. Там же были названы применения Apple кодов 95 и 112–114 без документации RFC. Документ просил сохранить эти назначения до решения рабочей группы DHC. Ключевым свидетельством была не публикация сама по себе, а сведения об использовании. RFC 3679

Это различие не означало, что любое недокументированное применение заслуживает постоянного публичного номера. RFC 3679 отдельно объяснял причины возврата кодов и рассматривал известные случаи PXE и Apple иначе. Возвращаемые номера следовало снова включить в доступный пул после исчерпания никогда не назначавшихся или ранее возвращённых кодов. Это информационный меморандум, а не доказательство, что каждая упомянутая реализация всё ещё существует или что все назначения были разрешены на практике. Статус RFC 3679

От перечня к переходному порядку

Позже в 2004 году RFC 3942 расширил пространство публично определённых DHCPv4-опций с 1–127 до 1–223, переклассифицировав верхнюю часть, прежде зарезервированную для частного использования. Такое изменение не могло стереть существующие локальные настройки. Поэтому стандарт ввёл переходный порядок: код с известным частным применением мог быть признан недоступным на время уведомления рабочей группы и IANA поставщиками; предварительное публичное назначение предусматривало шесть месяцев на уведомление и ещё восемнадцать месяцев на подачу Internet-Draft. Сайтам предлагалось перейти в оставшийся частный диапазон. RFC 3942

Правило разрешения конфликтов было жёстче. Если несколько поставщиков подтверждали достаточно широкое использование одного номера, ни один не мог оставить его за собой как частный код; каждый должен был запросить обычное публичное назначение. Это не объявляло частное использование неправомерным. Стандарт признавал, что один номер не может координировать два несовместимых смысла лишь потому, что каждый поставщик применял его локально. RFC 3942 также отверг 16-битное расширение, обременительное для первых внедривших его, и новый формат либо «магическую cookie», увеличивавшие затраты на совместимость и обнаружение.

Позднейший конфликт сделал различие наглядным

Позднее RFC 4578 описал опции PXE 93, 94 и 97 как широко используемые, но также отметил, что клиенты PXE запрашивали коды 128–135, официально не назначенные для PXE и способные конфликтовать с другими применениями в той же сети. Сам запрос клиента ещё не превращает код в официальное назначение.

Ещё более явный пример появился с captive portal. Изначально RFC 7710 использовал DHCPv4-опцию 160 для передачи URI портала. Во время сетевого эксперимента IETF 106 выяснилось, что некоторые устройства Polycom используют 160 для других целей; если передавать URI портала через этот код, они работали не так, как ожидалось. Поэтому RFC 8910 перенёс сигнал на опцию 114, обновил RFC 3679 и вернул 160 в состояние «не назначен», зафиксировав известное использование Polycom. Авторы описывают конфликт, наблюдавшийся в конкретном эксперименте, а не его распространённость во всех сетях. RFC 7710 RFC 8910

Текущая таблица IANA показывает дальнейшую судьбу нескольких номеров: 83 позднее используется для iSNS, 88 и 89 — для опций BCMCS, 114 — для Captive-Portal, а 96 остаётся неназначенным. Номера 126 и 127 также не назначены. Это состояние реестра, а не доказательство того, что устройства в действующих сетях не передают такие значения. Позднейшее назначение также не доказывает исчезновение всех прежних реализаций. Реестр параметров IANA BOOTP/DHCP RFC 4174 RFC 4280

В более поздней записке Лу Хэна № 72 есть ограниченная аналитическая параллель: запись о координации и операционная реальность — это разные виды свидетельств. Записка посвящена уникальности интернет-номеров, а не назначению DHCP-опций; она не вызвала и не одобряла решения этих RFC. Практический вывод следует из самих документов DHCP: прежде чем возвращать номер, нужно выяснить, используется ли он; повторное назначение — это переходный процесс, а не правка реестра. Записка № 72

Источники

Дополнительные протокольные материалы