Resumen

  • La opción 118 permitió solicitar una dirección de una subred distinta de aquella por la que el servidor recibió el mensaje DHCP; el lugar observado dejó de determinar por sí solo el pool.
  • La copia idéntica de la opción en la respuesta confirmaba un tramo del procesamiento, pero no acreditaba identidad, autorización sobre el pool, ruta, ausencia de conflicto ni servicio efectivo.

Un servidor DHCP suele comenzar con una inferencia. Si el mensaje pasó por un relay, giaddr ayuda a identificar la subred del cliente. Si no, la interfaz local que recibió el paquete ofrece una pista equivalente. En RFC 2131, esa información permite seleccionar el conjunto de direcciones apropiado.

El problema aparece cuando el emisor visible no es el usuario final. Un servidor de acceso remoto puede comunicarse con DHCP a través de una red interna y, al mismo tiempo, gestionar clientes conectados a redes externas. Incluso puede no existir conectividad IP directa entre ambos lados. La solicitud solo puede salir por dentro, aunque la dirección deba salir de un pool exterior.

RFC 3011, de noviembre de 2000, creó una expresión común para esa diferencia. La IPv4 Subnet Selection Option contiene una dirección de subred de cuatro octetos: cualquier dirección del segmento se combina con su máscara y los bits de host quedan a cero. IANA la conserva como la opción DHCP 118 en el registro de parámetros BOOTP/DHCP.

Cuando un servidor estaba configurado para admitirla, la opción tenía precedencia sobre la deducción ordinaria. La dirección ofrecida debía pertenecer a la subred indicada o a otra subred del mismo segmento de red. No podía proceder de un pool ajeno a ese límite.

La innovación no consistía únicamente en poder elegir “otra red”. Consistía en conservar dos afirmaciones que parecían incompatibles. El paquete había llegado de verdad por la red interna. La asignación debía producirse de verdad sobre la red externa. La primera era evidencia de transporte; la segunda, una instrucción de política.

Había además un tercer dato. El servidor necesitaba saber dónde devolver la respuesta. RFC 3011 exigía que todo mensaje con la opción 118 llevara en giaddr una dirección en la que el solicitante aceptara paquetes DHCP. Esto importaba durante la renovación: el servidor podía intentar dirigir un DHCPACK a la dirección asignada, aunque esa dirección no fuera enrutable desde la red interna. La opción elegía el pool; giaddr preservaba el retorno.

El protocolo incluyó una señal para redes mixtas. El servidor que procesara la opción debía devolver una copia idéntica, aunque el cliente no la hubiese incluido en la lista de parámetros solicitados. El cliente que dependía de ese comportamiento tenía que descartar cualquier DHCPOFFER o DHCPACK sin la opción.

Así se evitaba una compatibilidad falsa. Un servidor antiguo podía ignorar el código y ofrecer una dirección del pool interno. Un servidor capaz pero configurado para no usarlo podía hacer lo mismo. La respuesta seguiría teniendo forma DHCP, pero no cumpliría la selección solicitada. La ausencia del eco permitía distinguir esos casos.

El eco, sin embargo, era una prueba estrecha. Confirmaba que cuatro octetos habían atravesado una rama concreta de procesamiento. No identificaba de manera segura al dispositivo, no le concedía derecho sobre la subred, no demostraba que la dirección fuese enrutable o estuviera libre, y no probaba que el abonado recibiera tráfico. Un recibo de capacidad no es un título sobre el recurso.

La advertencia de seguridad de RFC 3011 se deriva de esa separación. DHCP no aportaba entonces autenticación por sí mismo. Si un cliente podía nombrar una subred remota, un atacante dejaba de estar limitado al pool asociado a su origen local. Podía distribuir solicitudes sobre un perímetro mayor de direcciones.

Por ello, el soporte debía estar desactivado por defecto. La habilitación tenía que ser deliberada y selectiva: para determinados identificadores de cliente, determinadas redes de origen o determinados destinos permitidos. La especificación creó un lenguaje interoperable; no otorgó una autorización universal.

La gramática provenía de RFC 2132. Código, longitud y valor hacían que la opción fuese legible. La autoridad para actuar sobre ella seguía viviendo en la configuración del servidor. Confundir esas capas equivaldría a decir que una frase bien formada debe ser obedecida.

La evolución posterior desplazó afirmaciones similares hacia intermediarios controlados por el operador. RFC 3046 definió Relay Agent Information y sus identificadores locales de circuito o extremo. RFC 3527 añadió la selección de enlace para que un relay pudiera señalar el segmento de asignación sin sacrificar la dirección con la que el servidor debía comunicarse con él.

Si coincidían la opción 118 del cliente y la subopción de enlace del relay, RFC 3527 daba prioridad a esta última. No era una preferencia estética. El relay ocupaba otra posición en el modelo de confianza y podía estar sujeto a controles del operador que un cliente arbitrario no tenía.

Incluso allí, la aparición de una subopción en la respuesta no bastaba siempre para probar que el servidor la había entendido; los contenedores podían copiar información. RFC 3527 exigía conocimiento administrativo de compatibilidad. RFC 3118 describió autenticación para mensajes DHCP, pero una norma disponible no equivale a una protección desplegada.

RFC 7969 revisó más tarde la personalización de DHCP según topología. Subnet Selection, Link Selection y Virtual Subnet Selection resuelven cortes distintos. Su coexistencia recuerda que origen físico, interfaz del relay, segmento lógico, VPN, pool y ruta de respuesta no son sinónimos.

Para reconstruir una asignación hay que conservarlos por separado: interfaz de entrada, fuente observada, giaddr, identificador del cliente, subred solicitada, regla aplicada, pool elegido, oferta, eco y destino de respuesta. Después vienen el registro del lease, la ruta, la resolución vecina, la entrega al usuario y el resultado de la aplicación.

La doctrina de Lu Heng sobre código ejecutable y capas de realidad encaja aquí sin forzar la historia. RFC 3011 estableció un mínimo común muy pequeño: cambió el selector del pool cuando el operador lo permitía. No declaró que la solicitud crease derechos, ni que el registro de IANA demostrase uso, ni que una oferta demostrase conectividad.

El paquete no mintió al venir de la red interna. La opción tampoco convirtió la red externa en origen. Ambas afirmaciones eran necesarias, y la respuesta seguía un tercer camino. La verdadera aportación de RFC 3011 fue impedir que un solo campo aparentara ser esas tres pruebas a la vez.

Sources