Resumen

  • En el acceso PPP, IPv6CP va después de LCP, mientras que la autenticación y autorización RADIUS pueden terminar antes de asignar una dirección. Por eso, el NAS quizá aún no sepa si el host usará IPv4, IPv6 o ambos.
  • RFC 3162 permitió incluir atributos de ambas familias en un mismo mensaje RADIUS y dejó al NAS aplicar solo los que el cliente pudiera usar. Un valor autorizado no demuestra que ya existan una dirección, un prefijo, una ruta o un servicio operativo.

La respuesta llegaba antes que la pregunta

Un servidor de acceso necesita una decisión de política antes de abrir la sesión de un abonado. Sin embargo, cuando pregunta a un servidor RADIUS si debe admitir al usuario, la configuración de capa de red que terminará usando el host puede seguir sin definirse. Ese orden es el aspecto más revelador de RFC 3162, “RADIUS and IPv6”, publicado en agosto de 2001.

La norma aborda dos tareas relacionadas, pero distintas. RADIUS puede operar sobre IPv6; por separado, los mensajes RADIUS pueden llevar atributos que permiten ofrecer acceso de red IPv6 a un usuario. La dirección IPv6 usada para transportar RADIUS no significa que al abonado ya se le haya asignado un prefijo IPv6. El documento trata ambos aspectos, pero el problema de secuencia pertenece al segundo.

RFC 3162 explica el momento usando el acceso con Point-to-Point Protocol. Link Control Protocol (LCP) ocurre antes que IPv6 Control Protocol (IPv6CP). La autenticación y autorización RADIUS pueden completarse antes de asignar direcciones. Así, cuando el Network Access Server (NAS) envía un Access-Request, puede que aún no sepa si el host utilizará IPv4, IPv6 o los dos.

Eso impide una solución sencilla: preguntar primero qué familia usará el cliente y devolver únicamente esos atributos. El NAS necesita la decisión antes de que la negociación posterior revele la respuesta. La solución de RFC 3162 no consiste en adivinar: permite que atributos relacionados con IPv4 e IPv6 coexistan en el mismo mensaje RADIUS y deja que el NAS decida cuáles se aplican. El NAS debería asignar únicamente direcciones y prefijos que el cliente pueda utilizar de verdad.

Autorizar no es configurar

Los propios atributos mantienen separadas esas funciones. NAS-IPv6-Address identifica el equipo que solicita autenticar al usuario. Framed-Interface-Id se refiere a un identificador de interfaz IPv6. Framed-IPv6-Prefix proporciona un prefijo y la ruta correspondiente para configurar al usuario. Framed-IPv6-Route aporta información de enrutamiento, mientras que Framed-IPv6-Pool nombra un conjunto configurado del que puede asignarse un prefijo. Son puntos de control diferentes, no pruebas intercambiables de conectividad.

Algunos valores se definen expresamente como sugerencias. Si IPv6CP negocia correctamente la opción Interface-Identifier, el NAS incluye en su Access-Request el identificador que prefiere. Se recomienda que el servidor RADIUS acepte la sugerencia, pero no está obligado a hacerlo. El NAS también puede proponer un prefijo IPv6; el servidor puede ignorarlo. Un Access-Accept es una respuesta de política, no un registro que demuestre que la interfaz del cliente aceptó la preferencia o que los paquetes ya alcanzan Internet.

RFC 3162 también limita el uso de los datos recibidos. No hace falta reservar una dirección IPv4 para un host que solo admite IPv6, ni un prefijo IPv6 para uno que solo usa IPv4 o 6to4. Es un consejo acotado que aclara responsabilidades: el servidor RADIUS aporta atributos de política; el NAS ve la sesión negociada y debe evitar configurar una familia que el cliente no puede usar.

El intercambio de autorización tolera así la incertidumbre al permitir una respuesta más amplia, y después restringe el uso efectivo en el punto que tiene mejor contexto sobre la sesión. No es solo una elección de formato de paquete. Es la frontera entre lo que un servidor central puede autorizar por adelantado y lo que un equipo de acceso solo puede conocer después de negociar el protocolo.

Las capas siguen separadas

Después vienen más pasos. Una solicitud puede incluir una preferencia del NAS. Una respuesta puede autorizar o devolver un prefijo. IPv6CP puede negociar un identificador de interfaz. El NAS puede configurar una dirección o ruta. Solo una prueba de extremo a extremo puede mostrar entonces si un servicio es alcanzable. RFC 3162 define atributos y su lugar en el intercambio; no documenta una sesión real de abonado ni certifica el resultado de esos pasos.

La diferencia importa porque a menudo se reducen autenticación, autorización y contabilidad a una sola palabra: “acceso”. Pero una respuesta de autenticación no equivale a una dirección configurada, y un prefijo instalado no significa que haya conectividad operativa. Quien revisa los registros necesita saber qué capa demuestra realmente cada evidencia.

RFC 3162 reservó seis números de atributo RADIUS, del 95 al 100, para información IPv6. Estándares posteriores añadieron vocabulario: RFC 4818 define un atributo de prefijo delegado, RFC 6911 incorpora otros atributos para acceso IPv6 y RFC 8044 actualiza la guía sobre tipos de datos en RADIUS. El documento de 2001 no es, por tanto, un inventario completo del aprovisionamiento moderno. Su aporte histórico es más preciso: hizo posible autorizar ambas familias antes de conocer la que usaría la sesión.

La Nota 20 de Lu Heng ofrece un marco editorial: la descripción formal y el estado observable de un sistema son capas distintas. Aplicado a esta RFC, un atributo registra lo que el servidor pidió, prefirió o autorizó; por sí solo no demuestra qué instaló el NAS ni a qué podía llegar el usuario. Es una lectura editorial, no una afirmación de los autores de RFC 3162.

Fuentes

  1. RFC 3162 — RADIUS and IPv6
  2. Ficha de RFC 3162 en RFC Editor
  3. RFC 2865 — Remote Authentication Dial In User Service (RADIUS)
  4. RFC 2866 — RADIUS Accounting
  5. RFC 2868 — RADIUS Attributes for Tunnel Protocol Support
  6. RFC 2472 — IP Version 6 over PPP
  7. RFC 2460 — Internet Protocol, Version 6 Specification
  8. RFC 3056 — Connection of IPv6 Domains via IPv4 Clouds
  9. RFC 4818 — RADIUS Delegated-IPv6-Prefix Attribute
  10. RFC 6911 — RADIUS Attributes for IPv6 Access Networks
  11. RFC 8044 — Data Types in RADIUS
  12. RFC 2044 — UTF-8, a Transformation Format of Unicode and ISO 10646
  13. Lu Heng, Nota 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile