Resumen

  • RFC 3361 dio a la opción 120 de DHCPv4 dos codificaciones excluyentes: nombres DNS preferidos o direcciones IPv4 ordenadas para localizar proxys SIP salientes.
  • Los nombres podían delegar transporte, puerto, instancia y sustitución al DNS; las direcciones fijaban un orden de hosts. La recepción de cualquiera de las formas no probaba la transacción SIP ni el resultado de la llamada.

El primer dato de una cadena suele recibir demasiado crédito. Un cliente obtiene una concesión DHCP, descubre un supuesto proxy local y parece listo para iniciar la comunicación. Sin embargo, entre “me dijeron dónde empezar” y “la ruta funcionó” quedan resolución, transporte, estado de transacción, encaminamiento SIP, negociación y medios.

RFC 3361, publicada en agosto de 2002 en el Standards Track, definió la opción 120 de DHCPv4 para indicar un proxy SIP saliente local. Un cliente SIP podía contactar directamente el destino del URI en algunas redes. En otras, por ejemplo cuando intervenían cortafuegos, necesitaba enviar las solicitudes por un servidor local. DHCP era una solución posible, no la única; la configuración manual seguía existiendo.

Después del código y la longitud de la opción aparecía un byte de codificación. El valor cero anunciaba una lista de nombres de dominio. El valor uno anunciaba una o más direcciones IPv4 binarias. Toda implementación debía admitir ambas posibilidades, aunque el texto prefería los nombres.

La diferencia no era meramente tipográfica. Un nombre abría el algoritmo de localización de RFC 3263. NAPTR podía anunciar los transportes disponibles; SRV, las instancias con puerto, prioridad y peso; y A o AAAA, las direcciones finales. El cliente cruzaba esa oferta con sus propias capacidades y política. El nombre transfería parte de la decisión a un grafo de servicio que podía cambiar sin renovar la concesión.

La lista IPv4 era más rígida. Las direcciones tenían orden de preferencia, pero la opción no transportaba el servicio NAPTR, el puerto SRV, su prioridad, su peso ni la descripción del transporte. Ponía candidatos concretos en el mensaje DHCP. Para moverlos, la administración necesitaba cambiar la configuración y esperar su nueva distribución.

Así, la forma elegida repartía el control. El administrador DNS podía mover o reordenar una oferta basada en nombres, mientras que el administrador DHCP dominaba directamente la secuencia literal. Ni uno ni otro controlaba por sí solo la versión del cliente, su caché, los transportes admitidos o el estado posterior del proxy.

RFC 3361 limitó además el significado de varios dominios. Debían representar dominios NAPTR distintos, posiblemente de proveedores diferentes, y no reemplazar varios registros A del mismo servicio. El cliente probaba cada dominio en el orden entregado. Solo avanzaba cuando el contacto fallaba, no había transporte común o la política local prohibía aquel dominio.

La selección era una escalera. DHCP ordenaba proveedores. NAPTR ordenaba servicios de transporte. SRV aplicaba prioridad y peso entre servidores. La resolución entregaba direcciones. La política y las capacidades del cliente descartaban opciones. El resultado visible —un host elegido— condensaba decisiones de varias autoridades.

RFC 3263 también fijó el momento en que la elección debía dejar de cambiar. Tras contactar con éxito un servidor para una transacción SIP, las retransmisiones, el CANCEL y el ACK correspondiente a una respuesta final no 2xx tenían que volver al mismo servidor. La búsqueda podía ser dinámica antes del contacto; la afinidad protegía el estado después.

El byte de codificación creó una regla de integridad semántica. El servidor no podía mezclar nombres y direcciones dentro de un mismo mensaje, aunque los pusiera en ocurrencias separadas de la opción 120. DHCP concatena primero las ocurrencias repetidas de una opción y las procesa después. Dos fragmentos válidos según gramáticas distintas formarían un objeto que el receptor interpretaría mal.

RFC 3396, publicada poco después, aclaró el orden exacto de esa concatenación y cómo repartir opciones largas entre ocurrencias y campos sobrecargados. También reconoció que muchos agentes DHCP desplegados no reconstruían opciones divididas. Una lista larga podía cumplir la especificación del emisor y fracasar en un cliente real.

RFC 3361 exigía ese mecanismo cuando la lista de dominios excedía la capacidad de una sola opción. La ruta podía romperse antes de consultar DNS: el servidor tenía una lista correcta, la red entregaba todos los fragmentos y el cliente, pese a ello, no reconstruía el mismo valor. La recepción del paquete no demostraba equivalencia de interpretación.

RFC 3319 mostró otra respuesta para DHCPv6 al año siguiente. Definió dos códigos separados: uno para dominios y otro para direcciones IPv6. Explicó que DHCPv6 no sufría escasez de códigos de opción, por lo que podía eliminar el byte de codificación. Las opciones quedaron más cortas, sencillas de analizar y mejor alineadas, y el cliente podía pedir una forma concreta. La presión sobre un registro había migrado a la complejidad de cada paquete IPv4.

Los nombres se codificaban como etiquetas de RFC 1035, con soporte obligatorio para compresión DNS y la expectativa de futuros nombres internacionalizados. Debajo de ellos, el modelo SRV de RFC 2782 y NAPTR, formalizado en RFC 3403, aportaban selección y reescritura de servicios. La opción 120 podía ser pequeña porque señalaba una infraestructura mucho mayor.

Esa infraestructura ampliaba el margen de operación y la superficie de confianza. RFC 3361 advirtió que quien modificara o insertara una respuesta DHCP podía llevar al agente SIP a un proxy malicioso, interceptar solicitudes o negar servicio. También podía omitir nombres que resolvieran a servidores SIP con TLS. El mensaje no era una llamada, pero podía decidir qué puerta recibiría toda la señalización y qué alternativas seguras ni siquiera serían consideradas.

El registro actual de IANA conserva el código 120 como SIP Servers DHCP Option. Esa fila demuestra coordinación duradera del número. No demuestra que una red lo ofrezca hoy, que un cliente lo solicite, que implemente ambas codificaciones ni que el proxy responda.

Una captura de la concesión tiene un alcance igualmente limitado. Puede probar los bytes recibidos y su forma. Para sostener que la ruta funcionó se necesitan respuestas NAPTR, SRV y de direcciones; selección de transporte y puerto; conexión con el proxy; respuesta de transacción; encaminamiento posterior; negociación de sesión; y evidencia de medios.

Conviene guardar cada recibo por separado. En DHCP: servidor, relé, bytes, forma, orden y vigencia. En DNS: respuestas, TTL, prioridad, peso y filtrado. En transporte: intentos y errores. En SIP: servidor elegido, identidad de transacción, respuestas y ruta siguiente. Después vienen sesión y medios, que tampoco se deducen de un 200 aislado sin contexto.

Dos ensayos de Lu Heng se usan aquí como lentes declaradas. “Minimum Initial Specification” ayuda a entender por qué una opción común y estrecha podía ser útil dejando proveedores, registros y despliegue en manos locales. “Reality Layers” impide convertir registro, configuración, resolución, implementación y resultado en una sola realidad. Son lecturas editoriales, no afirmaciones sobre la autoría o intención de RFC 3361.

La opción 120 señalaba un punto de encuentro. Su byte elegía entre delegar las decisiones siguientes al DNS o congelarlas parcialmente en una lista. La concesión podía nombrar la primera puerta. El funcionamiento del camino seguía pendiente de comprobación.

Fuentes