Кратко

  • RFC 3319 определил две опции DHCPv6 для поиска локальных исходящих SIP-прокси: упорядоченный список доменных имён и список IPv6-адресов.
  • Если клиент получил оба списка, он должен предпочесть имена и применить процедуры поиска SIP-сервера. Опции указывают кандидатов, но не подтверждают доверие к прокси или завершение звонка.

Аренда DHCP отвечала на более узкий вопрос, чем телефонный вызов

Задачу RFC 3319 легко описать неточно. SIP-клиент может знать адрес из SIP URI и всё же нуждаться в локальном исходящем прокси. Такой посредник может быть нужен из-за межсетевого экрана, местного плана набора, экстренных служб или других локальных условий. Прокси можно было настроить вручную; RFC предложил ещё один путь — получать кандидатов через DHCPv6.

Важна граница роли. RFC 3261 различает пользовательские агенты, прокси, серверы перенаправления и регистраторы. Под «SIP-сервером» RFC 3319 имеет в виду именно узел с исходящим прокси. Его присутствие в ответе DHCP не доказывает, что пользователь зарегистрирован, адресат разрешён, SIP-диалог завершён, медиапараметры согласованы или звонок состоялся.

Два формата и единый порядок предпочтения

Опция 21 OPTION_SIP_SERVER_D передаёт список доменных имён, а опция 22 OPTION_SIP_SERVER_A — список IPv6-адресов. Оба списка упорядочены по предпочтению; соответствующая спецификации реализация должна поддерживать обе опции. Клиент может запросить одну или обе через Option Request Option в DHCPv6. Ответ зависит от конфигурации сервера и запроса клиента. Даже запросив обе, сервер может вернуть только одну и должен предпочесть вариант с доменными именами.

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

Имя было входом для поиска SIP-сервера, а не заменой этого поиска

Доменные имена поступают в процедуру определения местоположения SIP-серверов из RFC 3263. RFC 3319 рекомендует, чтобы список ссылался на разные записи NAPTR, а не просто на разные записи A. Тогда один DHCP-сервер может указать прокси разных поставщиков. Но список не заменяет NAPTR или SRV: он даёт исходный набор доменов, после чего продолжают действовать механизмы SIP-поиска и правила транспорта.

Поэтому «резервный вариант» здесь означает конкретный переход. Имя в конце списка не становится автоматическим запасным адресом лишь оттого, что оно присутствует в пакете. Клиент переходит к нему после определённого сбоя. Если вместе с именами получены адреса, IPv6-список находится ещё дальше в цепочке предпочтения. DHCP передаёт кандидатов и порядок, а решения о разрешении имён, транспорте и допустимости остаются клиенту.

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

Точка конфигурации может также перенаправить доверие

Раздел безопасности описывает угрозу: если злоумышленник изменит или добавит ответ DHCP, пользовательский агент может быть направлен на мошеннический SIP-сервер. Тот может перехватывать запросы или отказывать в обслуживании. Подменённый ответ способен также исключить имена, ведущие к серверам с поддержкой TLS, и тем самым облегчить перехват.

Это модель угроз RFC, а не сообщение о состоявшейся атаке. Документ не утверждает, что любой полученный адрес аутентифицирован или что каждое имя ведёт к TLS. DHCP-ответ входит в цепочку доверия, поскольку влияет на следующий адрес отправки сигнализации. Проверка идентичности, политика и защита остальной системы по-прежнему необходимы отдельно. Найти сервер — не значит удостовериться в его личности.

Старая опция видна и в новых документах DHCPv6

Общая спецификация DHCPv6 обновилась: RFC 9915 заменил RFC 8415. При этом реестр кодов DHCPv6 Options у IANA по-прежнему связывает коды 21 и 22 с RFC 3319, а более поздний RFC 9243 содержит группы YANG для конфигурации обеих форм SIP-опций. Эти записи показывают сохранение ссылок в реестре и модели данных, но не измеряют применение операторами, поддержку клиентами, успешный переход к запасному варианту или завершение вызова.

Вклад RFC 3319 был уже и интереснее формулы «DHCP находит телефонный сервер». Он стандартизовал упорядоченное обнаружение локального исходящего прокси: сначала доменные имена, затем адреса при определённых условиях. Сам звонок остаётся за пределами опции. Механизм может указать, куда направить сигнализацию, но не удостоверяет, что произойдёт дальше.

Источники