Resumen

  • draft-ietf-intarea-dhcp-rate-signaling-00 permite que clientes, relés y conmutadores de inspección usen valores de velocidad, pero también permite que un relé DHCPv4 añada, cambie o quite la opción.
  • La auditoría debe preservar el valor original y cada mutación: recibir un número válido no demuestra quién lo seleccionó, a quién iba dirigido ni qué terminó aplicando el equipo.

Un relé de acceso recibe un DHCPACK con 800 Mbit/s. Su sistema AAA indica que la sesión pertenece a otro perfil, así que reemplaza el número por 500 Mbit/s antes de entregar el paquete al router del cliente. El router instala una cola a 500. En una captura junto al servidor aparece 800; en otra junto al hogar aparece 500. No hay que escoger cuál es «la verdadera» y borrar la otra. Hay que explicar la transición.

Esa posibilidad está en el diseño del nuevo DHCP Rate Option que estudia INTAREA. La opción transporta velocidades de subida y bajada y un tipo de cómputo de capa 2 o capa 3. El objetivo es que un equipo que desconoce el nivel provisionado pueda colocar shaping y gestión activa de colas cerca del cuello de botella. Relés y switches con DHCP snooping también podrían actuar.

La revisión 00, fechada el 27 de agosto de 2026, es un Internet-Draft informativo que expira el 28 de febrero de 2027. No es un RFC ni evidencia de despliegue por parte de un operador determinado. Los códigos solicitados aún pertenecen al proceso de estandarización.

La modificación autorizada no deja de ser una modificación

En DHCPv4, un agente de relé puede leer la opción para configurar su propio policer. También puede añadirla, modificarla o retirarla antes de reenviar el mensaje, por ejemplo después de obtener atributos de RADIUS u otra plataforma AAA.

La función puede ser legítima. El error probatorio aparece cuando el sistema borra el valor anterior. El cliente ya no puede demostrar qué seleccionó el servidor; el servidor tampoco puede explicar por sí solo qué recibió el cliente. La salida del servidor y la entrada del cliente son objetos de evidencia diferentes, unidos por un acto de transformación.

Ese acto necesita recibo: identidad del relé, versión del perfil AAA, sesión del abonado, valor anterior, valor posterior, razón, dirección, tipo de velocidad, instante, duración y destino de aplicación. RFC 3046 ofrece contexto para la información de relé y RFC 2865 para RADIUS, pero ninguna etiqueta sustituye la prueba de la decisión concreta.

Un tablero que muestra solamente 500 Mbit/s no distingue si el servidor los eligió, el relé los corrigió o el router los limitó por capacidad física. Tres mecanismos pueden terminar con el mismo número y repartir autoridad de manera muy distinta.

La propuesta del cliente no es el contrato

El borrador permite al cliente sugerir velocidades o expresar una preferencia entre capa 2 y capa 3. El servidor puede aceptar, rechazar o transformar esa propuesta. Su lógica queda fuera de la semántica cerrada del documento.

Por tanto, un valor en la solicitud prueba lo que el cliente pidió o declaró. No prueba la tarifa comprada, la capacidad del acceso ni el valor que la red decidió imponer. El servidor sigue siendo la autoridad para la opción que devuelve al cliente, aunque un intermediario autorizado pueda mutarla después.

Los estados del intercambio también limitan el poder del dato. Un valor en DHCPOFFER o ADVERTISE puede influir en la selección de servidor, pero no debe aplicarse a la interfaz. Solo DHCPACK o REPLY autorizan el cambio. Ver un número y poder actuar sobre él son hechos distintos.

El destino está dentro de la semántica

DHCPv6 permite una separación más visible. El servidor puede incluir una opción para el cliente y otras en envolturas RELAY-REPL destinadas a relés concretos. El valor del CPE y el del nodo de acceso pueden diferir deliberadamente para que el cuello de botella permanezca cerca del usuario mientras el relé tolera ráfagas.

Un relé debe consumir la opción de su propia envoltura. No debe excavar en la carga destinada al cliente para reutilizar una cifra. La posesión del paquete no otorga mandato sobre todos sus mensajes internos.

Registrar únicamente la cifra y el identificador de abonado no basta. Hay que conservar el nivel de encapsulación, el actor objetivo y el estado del protocolo. Dos números diferentes para dos destinos no son un conflicto. Un número tomado del destino equivocado sí es una violación de autoridad.

Una capa desconocida invalida la lectura cómoda

El tipo de velocidad evita confundir bytes de capa 2 con carga de capa 3. La diferencia puede parecer menor, pero basta para colocar mal la cola. El borrador exige ignorar subopciones desconocidas para permitir evolución; no permite, sin embargo, adivinar valores desconocidos de un campo conocido que define el significado del resto. Si el tipo es reservado o no se entiende, la opción completa se descarta y rige la configuración local.

Las apariciones repetidas se procesan en orden y gana la última. Si la canalización de logs convierte el paquete en un mapa sin orden, ya no puede reproducir lo que hizo el parser. «Paquete aceptado» tampoco equivale a «política de velocidad aceptada»: el arrendamiento puede completarse mientras la opción particular falla.

Aquí encaja la insistencia de Heng Lu en especificaciones iniciales mínimas y decisiones futuras localizadas. La capa común debe fijar solo lo necesario para interoperar —sentido, tipo, destino, estado y caducidad— sin convertir una opción en una autoridad general sobre política comercial o rendimiento.

La procedencia puede cambiar sin cambiar los dígitos

En doble pila, el borrador da preferencia a DHCPv6 cuando las señales difieren y exige conservar el protocolo origen. Si DHCPv4 y DHCPv6 anuncian ambos 300 Mbit/s, la expiración del arrendamiento v6 puede transferir la autoridad a v4 sin que cambie el número de la pantalla.

Eso no es continuidad probatoria. Cambian el servidor, el período de validez y quizá el camino de relés. Si tampoco queda un arrendamiento v4 válido, el equipo vuelve a la configuración predeterminada. En PPPoE, la señal DHCP prevalece sobre el valor de la autenticación PPP, pero la finalización de la sesión la revoca.

Un cero no describe una medición nula: indica velocidad sin restricción o retirada del limitador. Confundirlo con «capacidad 0» transforma una orden de limpieza en una falsa caída de servicio.

Un observador que programa hardware es un actuador

El switch de acceso puede inspeccionar DHCP y convertir el valor en una cola o policer. Desde ese momento ya no se limita a observar. Su decisión afecta el tráfico del abonado y necesita la misma atribución que cualquier otro cambio de control.

El recibo debe unir paquete, puerto de confianza, sesión, objetivo, capacidad de interfaz, tope local, transacción de configuración y lectura posterior del hardware. La captura demuestra que un campo pasó por el switch; no demuestra que el campo iba dirigido al switch ni que la programación tuvo éxito.

Esta separación es decisiva para soporte. Si el cliente recibe 500 y el switch aplica 450 por una política local, la señal no explica por sí sola la experiencia. El valor señalado, el interpretado, el efectivo y el observado merecen columnas diferentes.

Un canal sin autenticar puede producir una orden válida y hostil

DHCP suele operar en texto claro y sin autenticación. Un servidor falso o un atacante en ruta puede inyectar una cifra baja. La conectividad IP puede seguir funcionando mientras el servicio útil queda estrangulado. Un umbral de cordura filtra extremos y un límite físico acota excesos, pero ninguno prueba quién emitió la orden.

RFC 3118 describe autenticación DHCP. Citarla no demuestra que esté desplegada. La evaluación debe verificar controles existentes: puertos confiables, validación de cadena de relés, binding entre sesión y abonado, protección de snooping, lista de servidores y trazabilidad del registro AAA.

El borrador compara este riesgo con ataques DHCP potencialmente más graves, como gateway o DNS falsos. Eso no vuelve inocua la manipulación de velocidad. Solo indica que el protocolo ya vive dentro de una frontera de confianza amplia y delicada.

Aplicar una cola no demuestra mejorar la latencia

Conocer bien el cuello de botella ayuda a configurar shaping y AQM. RFC 7567 expone el daño de las colas persistentes y RFC 9330 describe el funcionamiento de L4S. Ninguno convierte la recepción de una opción en resultado de rendimiento.

Después del commit hay que medir: configuración efectiva, ocupación, marcas, descartes, latencia, caudal, errores y rollback. La opción es una intención; la programación es una acción; el resultado necesita observación independiente.

La contribución duradera del mecanismo puede ser pequeña y valiosa: un vocabulario interoperable para llevar una señal de velocidad. Su límite también debe ser explícito. No certifica el contrato, no mide el enlace, no vuelve transparente al relé y no demuestra el beneficio de una cola.

Incertidumbre

El texto puede revisarse, reemplazarse o expirar. No se ha verificado aquí ninguna implementación pública, equipo concreto ni red de producción. Las ventajas anunciadas son una justificación técnica pendiente de validación en cada entorno y modelo de amenaza.

Fuentes