Кратко

  • RFC 3361 определил для опции DHCPv4 120 две взаимоисключающие кодировки: предпочтительный список имён DNS или упорядоченный список IPv4-адресов локальных исходящих SIP-прокси.
  • Имя могло передать DNS выбор транспорта, порта, экземпляра и резерва; адреса фиксировали очередь хостов. Ни одна форма не доказывала последующую SIP-транзакцию или полный путь вызова.

Настройка приходит раньше пользовательского результата и потому кажется способной объяснить его целиком. Устройство получает аренду DHCP и адрес местного SIP-прокси, после чего путь будто известен. Но между стартовой координатой и разговором остаются разрешение имени, транспорт, состояние транзакции, дальнейшие прокси, согласование сеанса и медиа.

RFC 3361 был опубликован в августе 2002 года на Standards Track и определил опцию DHCPv4 120. В одних сетях SIP-клиент мог напрямую обратиться к цели URI. В других, например при наличии межсетевых экранов, исходящие запросы требовали местного сервера. DHCP был одним из способов обнаружения, а ручная настройка оставалась альтернативой.

После кода и длины находился байт кодировки. Ноль означал последовательность доменных имён, единица — один или несколько двоичных IPv4-адресов. Все реализации должны были поддерживать обе формы, хотя документ предпочитал имена.

Это не две записи одного факта. Домен открывал процедуру RFC 3263. NAPTR мог объявить доступные транспорты, SRV — экземпляры, порты, приоритеты и веса, A или AAAA — адреса. Клиент пересекал предложение домена со своими возможностями и политикой. Имя делегировало следующий выбор изменяемому графу службы.

Список IPv4 содержал меньше контекста. Адреса шли в порядке предпочтения, но опция не несла службу NAPTR, порт SRV, приоритет, вес или описание транспорта. Она замораживала кандидатов в DHCP-настройке. Их изменение зависело от обновления и повторной раздачи.

Форма определяла место власти. Администратор DNS мог перемещать экземпляры и менять порядок без новой аренды. Литеральный список отдавал больше прямого контроля DHCP. Однако версия клиента, кэш, поддерживаемый транспорт, политика и фактическое состояние прокси не подчинялись полностью ни одной стороне.

Несколько доменов тоже имели узкий смысл. Они должны были обозначать разные домены NAPTR, например разных поставщиков, а не заменять несколько A-записей одного домена. Клиент пробовал их по порядку и переходил к следующему лишь после ошибки контакта, отсутствия общего транспорта или запрета локальной политики.

Получалась лестница порядков. DHCP располагал домены поставщиков. NAPTR выбирал транспортные службы. SRV применял приоритет и вес к экземплярам. Разрешение давало адреса. Возможности и политика клиента отбрасывали кандидатов. Один итоговый хост сжимал решения нескольких административных поверхностей.

RFC 3263 задавал границу изменения. После успешного контакта с сервером для SIP-транзакции повторные передачи, CANCEL и ACK для финального ответа не-2xx должны были идти тому же серверу. До контакта обнаружение могло быть динамичным; после появления состояния требовалась привязка.

Байт кодировки создавал ещё одно правило. Сервер не мог смешивать имена и адреса в одном DHCP-сообщении даже в отдельных экземплярах опции 120. DHCP сначала соединяет повторные опции и лишь потом разбирает содержимое. Два правильных по отдельности фрагмента с разными грамматиками превращались в неверный общий объект.

RFC 3396 позднее уточнил порядок соединения и способ делить длинные опции между экземплярами и перегруженными полями. Он также отметил, что многие развёрнутые DHCP-агенты не собирали части. Отправитель мог действовать по стандарту, а реальный получатель не восстанавливал значение.

RFC 3361 требовал этот механизм для списка имён длиннее одной опции. До первого DNS-запроса длинный список уже зависел от порядка фрагментов и реализации клиента. Факт передачи всех байтов не доказывал одинаковое понимание.

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

Имена использовали метки RFC 1035 и сжатие DNS, в том числе с расчётом на будущие интернационализированные имена. Ниже работали SRV из RFC 2782 и NAPTR из RFC 3403. Небольшая опция ссылалась на большую независимо управляемую систему.

Косвенность расширяла гибкость и доверие одновременно. RFC 3361 предупреждал, что изменённый или вставленный ответ DHCP может отправить агент к чужому SIP-серверу, позволить перехват запросов или отказ в обслуживании. Из ответа можно удалить имена TLS-серверов. Аренда не несла разговор, но могла выбрать первую дверь сигнализации и скрыть безопасные варианты.

Современный реестр IANA продолжает связывать код 120 с SIP Servers DHCP Option. Строка доказывает координацию номера, но не современную раздачу, поддержку, использование или доступность прокси.

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

Для DHCP сохраняются сервер, relay, исходные байты, форма, порядок и срок. Для имён — NAPTR, SRV, A/AAAA, TTL и выбор после фильтра. Для адресов — очередь попыток, порт и транспорт. Отдельно фиксируются контакт прокси, SIP-ответ, следующий маршрут, описание сеанса и медиапоток.

Два текста Lu Heng открыто используются как аналитические линзы. “Minimum Initial Specification” показывает ценность узкой общей опции, оставляющей поставщика, DNS и внедрение локальным решениям. “Reality Layers” разделяет зарегистрированный код, доставленную настройку, разрешённую службу, работающую реализацию и результат вызова. Это редакционное чтение, а не заявление об авторстве или намерении RFC 3361.

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

Источники