Resumen

  • RFC 3993 permite que un relay DHCP agregue un Subscriber-ID asignado por el proveedor y pensado para seguir siendo estable cuando el cliente cambia de ruta física de acceso.
  • La norma transporta el valor, pero deja su asignación y sentido a la configuración del proveedor; así sirve a la continuidad de políticas y puede facilitar correlaciones prolongadas.

Cambiar de circuito sin cambiar de ficha

Un servidor DHCP a veces debe decidir por un cliente que no ve directamente. En una red de acceso extensa, el relay recibe la difusión local del cliente y la reenvía a un servidor central. Puede añadir información sobre el punto por el que la solicitud entró en la red del proveedor. El servidor puede asignar entonces una dirección y otros parámetros sin instalar un servidor en cada segmento.

El relay se convierte en observador y mensajero. RFC 3046, publicada en 2001, le dio un contenedor para la información del agente relay. Entre sus primeros campos estaban Circuit-ID y Remote-ID: uno podía describir el circuito de entrada y el otro un módem remoto. Estos valores ayudaban a distinguir líneas y equipos, pero seguían la topología. Si el cliente cambiaba de ruta, el valor ligado al circuito podía variar aunque el proveedor quisiera mantener el mismo tratamiento administrativo.

RFC 3993, publicada en 2005, añadió Subscriber-ID al contenedor existente. El valor podía ser independiente de la estructura física de acceso y mantenerse estable cuando el cliente cambiaba de ruta o la red evolucionaba. El proveedor podía usarlo junto a los identificadores de circuito y equipo, en lugar de pedirle a un solo campo que representara ambas cosas.

El formato transporta; no interpreta

La contención de la norma es lo decisivo. Subscriber-ID es una cadena NVT ASCII del suboption 6, precedida por un campo de longitud de un octeto. Debe tener al menos un octeto y no termina en NUL. Esas reglas permiten encontrar el valor en el mensaje. No explican qué significan sus caracteres.

RFC 3993 dice que el significado depende del proveedor. Este asigna el identificador, y los mecanismos de asignación y configuración quedan fuera del documento. El relay puede configurarse para incluirlo. Un servidor compatible puede utilizarlo junto con otros datos del relay y del cliente al asignar una dirección u otros parámetros. Ni la presencia ni el uso son obligatorios.

La separación hace que la etiqueta pueda viajar sin convertirla en algo universal. Un proveedor quizá vincule el valor a una cuenta de facturación; otro, a un perfil de servicio. La norma no obliga a ninguno de esos modelos ni exige que una misma cadena signifique lo mismo en otro dominio administrativo. Por sí solo, un paquete DHCP no demuestra la identidad de una persona, un equipo, un contrato o un derecho de acceso. Esos vínculos viven en los registros y decisiones del proveedor.

El añadido fue pequeño en el cable, pero importante para el control. El cliente no presenta la etiqueta estable como una identidad que él mismo declara. La inserta un relay operado por el proveedor, y el servicio central puede usarla para decidir una dirección o configuración. La autoridad del valor procede de la relación de confianza y de la tabla de correspondencias del proveedor, no de la cadena de caracteres.

La confianza vuelve decisivo el atajo

La opción de información del relay presupone una relación de confianza entre el relay y el servidor. RFC 3993 advierte que datos falsos podrían contribuir al robo de servicio, al agotamiento de direcciones escasas, a la denegación de servicio o a parámetros inadecuados. Según RFC 3046, el servidor que reconoce la opción la devuelve al relay, que la retira antes de responder al cliente. Este intercambio interno no es un certificado de identidad que se entregue al usuario.

La frontera se puede proteger mejor. RFC 3993 menciona defensas perimetrales y recomienda añadir protección mediante la subopción de autenticación del relay o IPsec. RFC 4030 especifica esa subopción, incluida la detección de repetición de mensajes. La autenticación puede ayudar a verificar que los datos llegaron por una ruta aceptada; no aporta el significado específico del proveedor que RFC 3993 deja sin definir.

La estabilidad también tiene un coste de privacidad. Un identificador de circuito puede mostrar por dónde entró un mensaje. Uno de abonado puede seguir al mismo sujeto entre circuitos. RFC 3993 advierte que el valor podría identificar un equipo o usuario si se expone. RFC 7819 trata Subscriber-ID como posible identificador duradero que permite vincular actividad a lo largo del tiempo. El beneficio que reduce cambios de configuración puede alargar el periodo durante el cual se relacionan registros.

RFC 4580 llevó una idea semejante a DHCPv6. También deja la asignación y el sentido fuera de la norma y destina el intercambio a un único dominio administrativo. Esa continuidad confirma un patrón de diseño, pero no hace equivalentes por defecto los identificadores de DHCPv4 y DHCPv6.

Las RFC documentan el mecanismo y los riesgos que describen. No prueban su nivel de adopción, una migración real de abonado ni los controles de privacidad de un operador concreto. La historia está en el límite de diseño: DHCP pudo transportar la etiqueta estable de un proveedor a través de una topología cambiante; el proveedor siguió respondiendo por lo que significaba y por las decisiones que provocaba.

Fuentes