Resumen

  • La opción 121 de RFC 3442 permitió que DHCPv4 distribuyera rutas con longitudes de prefijo explícitas, frente al supuesto de clases de direcciones de la opción estática anterior.
  • Un cliente compatible debía instalar esas rutas y darles prioridad frente a Router y la opción 33 cuando llegaban juntas; el RFC advertía que un siguiente salto incorrecto podía desviar el tráfico.

Una concesión de dirección parece una asignación: la red indica a un equipo qué dirección puede usar y durante cuánto tiempo. Pero el equipo también debe saber adónde enviar los paquetes que no son locales. RFC 3442 incorporó esa segunda decisión a la conversación de configuración DHCP. Su opción de rutas estáticas sin clases podía transportar un prefijo de destino y la dirección del router que debía alcanzarlo.

El cambio resolvía un desajuste. La opción 33 de DHCP, definida en RFC 2132, describía rutas estáticas sin una máscara independiente para cada destino. Eso presuponía que el límite de red podía deducirse de la clase de dirección. El enrutamiento sin clases ya había desplazado esa lógica: 10.0.0.0/8 y 10.0.0.0/24 son destinos distintos, aunque compartan los primeros octetos. El cliente necesita la longitud del prefijo para saber qué bits definen la ruta.

La opción 121 codificó ese alcance de forma compacta. El descriptor del destino empezaba con la longitud del prefijo e incluía solo los octetos significativos; después venía una dirección de router de cuatro octetos. El cliente reconstruía el destino y ponía a cero los bits fuera de la máscara antes de instalar la ruta. RFC 3442 no convirtió DHCP en un protocolo de enrutamiento ni distribuyó una tabla de Internet. Permitió que un administrador usara un servidor que ya configuraba equipos para instalar rutas estáticas seleccionadas en los clientes.

Así se desplazó una decisión importante entre superficies administrativas. La tabla de rutas seguía en el equipo y el cliente aplicaba sus propias reglas de procesamiento. Sin embargo, una ruta podía originarse en la configuración del servidor DHCP y no en una edición local del dispositivo. Para los clientes que admitían la opción 121, el RFC exigía instalar las rutas, con una excepción para subredes locales. Si la nueva opción aparecía junto a Router o a la opción 33, el cliente debía ignorar esos valores anteriores.

También importaba el orden de solicitud: la opción 121 debía preceder a Router y a la opción 33 en la lista de parámetros solicitados.

La compatibilidad era parte del diseño. Los clientes que no implementaban la opción 121 debían ignorarla. Por eso RFC 3442 recomendó que los administradores enviaran también la opción Router, duplicando la información de router predeterminado para los equipos antiguos. Era una estrategia de transición, no una prueba de cuántos dispositivos eran compatibles ni de la velocidad de adopción. Una especificación puede establecer una regla de prioridad; no puede hacer que todos los clientes la implementen.

El límite tenía una consecuencia de seguridad. RFC 3442 advertía expresamente que una dirección incorrecta de router podía causar denegación de servicio o hacer que el tráfico pasara por un observador. El riesgo no era exclusivo de la opción 121: Router y la antigua opción de rutas también podían apuntar al siguiente salto equivocado. La opción no demostraba que la ruta propuesta estuviera autorizada, fuera correcta o segura. La autenticación de mensajes, cuando se usaba, pertenecía a otro mecanismo DHCP y no bastaba para demostrar que la decisión de ruta fuera sensata.

El tamaño del paquete también condicionaba la entrega. Una lista extensa podía superar el tamaño tradicional de los mensajes DHCP; RFC 3442 trató la negociación de mensajes mayores y exigió compatibilidad con la concatenación de opciones largas. En enlaces compartidos por varias subredes IP, también definió el uso especial del siguiente salto 0.0.0.0 para indicar una subred local directamente alcanzable. Los clientes sin la funcionalidad de pila necesaria debían ignorar esa entrada.

El cambio histórico de RFC 3442 fue limitado, pero revelador: cuando el enrutamiento dejó de basarse en clases, la configuración de direcciones necesitó expresar también el alcance de cada ruta. La concesión podía convertirse en vehículo de política de reenvío local. El cliente seguía siendo el punto de instalación, el administrador del servidor pasaba a elegir rutas y el siguiente salto tenía consecuencias que iban más allá de asignar una dirección.

Fuentes