Resumen

  • RFC 3319 definió dos opciones DHCPv6 para descubrir proxies SIP locales de salida: una lista ordenada de nombres de dominio y otra de direcciones IPv6.
  • Si llegaban ambas, el cliente debía preferir los nombres y aplicar las reglas de localización SIP; eran destinos candidatos, no una prueba del proxy ni de que la llamada se completara.

Encontrar un intermediario no era lo mismo que completar una llamada

El problema de RFC 3319 puede contarse de manera demasiado amplia. Un cliente SIP puede conocer la dirección escrita en un URI SIP y aun necesitar un proxy local de salida. Un cortafuegos, un plan de marcación local o ciertos servicios del entorno pueden hacer necesario ese intermediario. La configuración manual era una opción; el RFC añadió otra: DHCPv6 podía anunciar candidatos para que el cliente los probara.

La palabra «proxy» delimita el alcance. RFC 3319 se refiere al equipo que ejecuta un proxy saliente, no al servicio telefónico entero. RFC 3261 distingue agentes de usuario, proxies, servidores de redirección y registrars. Que un proxy figure en una respuesta DHCP no demuestra que el usuario esté registrado, que el destino esté autorizado, que el diálogo SIP haya terminado o que circule audio.

Dos formatos, un orden de preferencia

La opción 21, OPTION_SIP_SERVER_D, lleva nombres de dominio; la 22, OPTION_SIP_SERVER_A, direcciones IPv6. Ambas listas están ordenadas por preferencia. Una implementación conforme debe admitir los dos formatos. El cliente puede pedir uno o ambos mediante la Option Request Option de DHCPv6. La respuesta del servidor depende de su configuración y de la petición; incluso cuando se solicitan ambos, puede devolver solo uno y debería preferir la lista de nombres.

Si llegan las dos, el cliente debería empezar por los nombres. Las direcciones numéricas son un recurso condicionado: solo puede usarlas si ningún nombre de la primera lista se resuelve o resulta alcanzable. Tampoco tiene que resolver de inmediato todos los nombres siguientes. Recorre el orden recibido y avanza cuando falla el intento anterior, no existe un transporte común o una política del cliente prohíbe ese dominio.

El nombre alimentaba la localización SIP, no la sustituía

El cliente procesa los nombres mediante las reglas de localización de servidores de RFC 3263. Los nombres deberían corresponder a registros NAPTR distintos y no limitarse a distintos registros A. RFC 3319 explica que varios nombres permiten que un solo servidor DHCP indique proxies operados por diferentes proveedores. Sin embargo, la lista no sustituye a NAPTR ni SRV: sigue haciendo falta el mecanismo de localización y selección del transporte SIP.

Por eso «respaldo» tiene aquí una condición concreta. Una dirección IPv6 no es otra lista que deba probarse siempre después de cualquier nombre; entra en juego cuando no se puede resolver o alcanzar ninguno de los nombres. Del mismo modo, el siguiente dominio no se convierte automáticamente en respaldo solo por aparecer después en el paquete. El cliente conserva decisiones sobre resolución, transporte y política mientras DHCP distribuye candidatos y su orden.

La división podía facilitar la operación: la red entregaba opciones de servicio locales sin fijar un único proxy dentro de cada cliente. Pero la respuesta tampoco añadía evidencia sobre el servicio. Un host puede estar en la lista y no contestar, no compartir un transporte útil o rechazar la solicitud. «Configurado como preferido» y «usado con éxito» son estados distintos.

El canal de configuración también puede desviar el destino

La sección de seguridad describe una consecuencia concreta. Si un atacante modifica una respuesta DHCP o inserta otra, puede conducir al agente de usuario hacia un proxy SIP malicioso, capaz de interceptar solicitudes o denegar el servicio. Una respuesta alterada también podría omitir nombres que resolvieran a servidores preparados para TLS, facilitando la interceptación.

Ese es el modelo de amenaza del RFC, no una denuncia de un ataque ocurrido. Tampoco afirma que toda dirección recibida autentique al servidor ni que cada nombre lleve a TLS. La respuesta DHCP forma parte de la cadena de confianza porque influye en el siguiente destino de la señalización. La identidad, las protecciones y la política del resto del sistema siguen siendo cuestiones separadas. Encontrar un servidor no equivale a autenticarlo.

La opción sigue visible en registros posteriores

RFC 9915 es la especificación general actual de DHCPv6 y reemplazó a RFC 8415. Aun así, el registro de códigos de opción DHCPv6 de IANA conserva los códigos 21 y 22 con RFC 3319 como referencia; RFC 9243 incluye después agrupaciones YANG para configurar ambas formas de la opción SIP. Eso demuestra continuidad en el registro y en un modelo posterior, no frecuencia de uso, compatibilidad real ni tasas de llamadas completadas.

La aportación de RFC 3319 fue más limitada —y más útil— que «DHCP encuentra el servidor telefónico». Formalizó una forma ordenada de descubrir un proxy local de salida: primero nombres y, bajo condiciones, la lista de direcciones. La llamada quedaba después; la opción podía orientar la señalización, no certificar su resultado.

Fuentes