Resumen

  • RFC 4014 permitió que el NAS conservara parte de los atributos de un Access-Accept de RADIUS y los enviara después dentro de la opción de información del relay DHCP.
  • El servidor DHCP utilizaba esos datos para seleccionar parámetros. La autorización, el transporte por el relay y la asignación de dirección seguían siendo funciones distintas.

Dos intercambios, una sola sesión de red

La autorización puede terminar antes de que empiece la configuración. Un equipo se conecta a una red inalámbrica o a un puerto Ethernet. El acceso 802.1X se aprueba. El conmutador o punto de acceso permite que la sesión continúe. Pero el equipo todavía necesita completar DHCP para recibir su configuración IP. Entre el “puedes entrar” y el “así te configuras” hay un pequeño intervalo que atraviesa dos servicios diferentes.

RADIUS responde a una pregunta de acceso: si se autoriza la sesión y qué atributos de servicio acompañan esa decisión. DHCP responde otra: qué parámetros debe ofrecer el servidor a ese cliente. RFC 3580 es explícito en que IEEE 802.1X no asigna direcciones IP; incluso Framed-Pool sólo sirve cuando el autenticador puede participar en esa asignación.

En una red real, ambas funciones podían pertenecer a equipos separados. Un servidor RADIUS central gestionaba autenticación. Un servidor DHCP remoto mantenía los pools. El NAS —por ejemplo, el conmutador del borde— conocía la sesión que acababa de aceptar y hacía de relay DHCP. El desafío no era inventar una autoridad única, sino transportar suficiente contexto entre quienes ya tomaban decisiones separadas.

RFC 4014, publicado en febrero de 2005 por Ralph Droms y John Schnizlein, formalizó ese transporte. Tras un Access-Accept exitoso, el NAS conservaba atributos localmente. Cuando más tarde retransmitía la petición DHCP del cliente, podía incluir una selección acotada de esos atributos. La norma no convertía una autorización de RADIUS en un lease; conectaba una decisión con la otra.

El relay ya hablaba por la red de acceso

La pieza de transporte venía de antes. RFC 3046 había creado Relay Agent Information, también llamada Option 82, como un contenedor para información que el relay conocía directamente. Sus primeros subcampos identificaban el circuito por el que entraba la petición o el dispositivo remoto. El servidor DHCP podía usar esa información para elegir una dirección u otros parámetros.

El servidor devolvía esa opción en su respuesta, y el relay la eliminaba antes de enviarla al cliente. Así, el equipo final no necesitaba conocer las etiquetas internas de la red de acceso. El relay actuaba como frontera entre la petición del cliente y la información de la infraestructura.

RFC 4014 añadió dentro de Option 82 la subopción 7, denominada “RADIUS Attributes”. El NAS podía copiar allí la codificación de atributos recibidos en el Access-Accept. El servidor DHCP extraía el contenido para elegir configuración. El relay transmitía contexto; el servidor DHCP conservaba la elección final.

La norma ponía límites deliberados. Un mensaje no podía contener más de una subopción de RADIUS Attributes. El relay debía incluir User-Name y Framed-Pool cuando estuvieran disponibles, y podía incluir otros atributos. Para evitar que la asignación de direcciones dependiera de un estado separado que sólo conociera RADIUS, RFC 4014 recomendó una lista de seis: User-Name, Service-Type, Vendor-Specific, Session-Timeout, Framed-Pool y Framed-IPv6-Pool.

El servidor DHCP debía usar la información para seleccionar parámetros e ignorar los atributos que quedaran fuera de la lista. Un nombre de pool podía ayudar a identificar una política, pero no obligaba al servidor a conceder una dirección. La decisión de RADIUS influía en el contexto; el servidor DHCP seguía controlando los recursos que administra.

El límite también era físico

La subopción tenía una capacidad finita. RFC 4014 indica que el relay trunca los atributos para que quepan; no define una regla general que diga cuáles deben sobrevivir. Por eso, que un atributo aparezca en el Access-Accept no garantiza que llegue completo al servidor DHCP. El tamaño de la opción y la selección de atributos forman parte del comportamiento que el operador debe observar.

También queda una tarea de estado en el NAS. Debe conservar el contexto correcto para la petición DHCP posterior. El estándar no prescribe cómo mantener una tabla de sesiones, ni cómo actualizarla después de una nueva autenticación o un cambio de política. Esas preguntas no invalidan el mecanismo; muestran dónde termina el protocolo y empiezan las decisiones de implementación.

RFC 4014 limita la interoperabilidad robusta a un mismo dominio administrativo localizado. El intercambio presupone que RADIUS, el NAS y DHCP comparten un significado local para los atributos. No es un contrato global entre redes independientes. RFC 3046 ya había situado la confianza entre relay y servidor en el centro de Option 82; RFC 4014 recomienda una protección adicional, como autenticar las opciones de relay o usar IPsec, además del filtrado perimetral.

Que el cliente no vea Option 82 reduce lo que tiene que procesar, pero no autentica por sí solo el contenido. Si un servidor confiara en un relay falso o en estado vencido, una rama de política podría tomar una decisión inadecuada. Esa es una consecuencia posible de la arquitectura, no una afirmación de que haya ocurrido un incidente concreto.

Lo que cambió en 2023

RFC 9445 retomó la cuestión cuando los nuevos servicios necesitaron opciones DHCP más flexibles. Actualizó RFC 4014 al sustituir su lista fija por un registro IANA de atributos RADIUS permitidos en la subopción. La lista ahora puede ampliarse bajo revisión experta.

El mismo RFC define, además, dos atributos RADIUS distintos para transportar opciones DHCP: DHCPv6-Options (245.3) y DHCPv4-Options (245.4). Su ejemplo de DNS cifrado ilustra un servicio que puede configurarse de este modo; no demuestra cuántas redes lo han desplegado. Estos atributos nuevos no son la antigua subopción 7. En la actualidad, el registro IANA indica permisos y asignaciones, no el uso efectivo en producción.

La línea histórica es más precisa si se conserva esa diferencia: primero, una lista limitada de atributos de autorización que el relay podía llevar al servidor DHCP; después, un registro extensible para esa subopción y un mecanismo separado para llevar opciones DHCP dentro de RADIUS. En ambos casos, el objetivo fue cruzar la información entre servicios sin borrar sus responsabilidades.

La Nota 64 de Lu Heng ofrece una lectura posterior: una especificación común mínima puede dejar las decisiones siguientes en manos del dominio que opera los equipos. La Nota 65 añade una prueba práctica: publicar una regla no demuestra que el código que corre la aplique. Son lentes de análisis posteriores, no fuentes ni causas de RFC 4014. Para saber quién eligió realmente la configuración, hay que seguir la evidencia desde el Access-Accept, pasando por el relay, hasta la decisión y la respuesta del servidor DHCP.

Fuentes