Resumen

  • draft-ietf-intarea-dhcp-rate-signaling-00 define tasas ascendentes y descendentes de 64 bits y un tipo que diferencia información, capa 2 y capa 3. Es una señal de política, no un sensor de capacidad instantánea.
  • Un cliente puede sugerir; el servidor responde; un relay puede insertar o sustituir; y DHCPv6 puede dirigir valores distintos a varios niveles. «Vino por DHCP» no identifica por sí solo al principal ni al ejecutor.
  • La prueba completa necesita conservar origen y vigencia, leer la configuración efectiva, demostrar qué cola está activa y observar el tráfico. Sin esa cadena, un valor correcto puede terminar aplicado en la interfaz equivocada o coexistir con un cuello de botella menor.

Imagine una línea comercializada a 1 Gbit/s. El CPE recibe exactamente ese valor en un DHCPACK. Su panel lo presenta como velocidad disponible y una tarea automática configura una cola. El soporte ve tres marcas verdes: opción recibida, configuración aceptada y enlace físico a 2,5 Gbit/s. Sin embargo, una subida sostenida dispara la latencia.

La explicación puede estar fuera de esas tres marcas. El valor quizá contabilice trama Ethernet y el panel lo compare con carga IP. El policer del operador puede estar un poco por debajo. La disciplina de cola pudo quedar ligada al dispositivo lógico equivocado. El relay pudo reemplazar un perfil. O la congestión puede aparecer más lejos, donde el CPE no tiene autoridad.

No es un incidente documentado, sino una prueba mental. La revisión 00 permite coordinar una decisión; no da fe de que la decisión se ejecutó ni de que controló el resultado.

Política, control y resultado son libros distintos

La primera obligación de un sistema de observabilidad es no guardar objetos diferentes bajo el mismo nombre.

Libro Registro correcto Pregunta que queda abierta
Política bytes de OPTION_RATE, mensaje, transacción, lease, dirección, tipo, servidor/relay ¿se instaló algo?
Control equipo, interfaz, cola, algoritmo, valor efectivo, versión y lectura posterior ¿esa era la cola limitante?
Resultado caudal, latencia, pérdida, marcas ECN y carga medida en un intervalo ¿qué intención o autoridad originó el límite?

El borrador transporta el primer registro para facilitar el segundo. El tercero procede del tráfico. Convertir los tres en una columna llamada bandwidth elimina precisamente la información necesaria cuando algo falla.

Un bit por segundo no está completo sin su capa

Las dos tasas direccionales son enteros sin signo de 64 bits. Rate Type define su universo contable. El tipo 2 es capa 2: incluye cabecera Ethernet y carga, excluye FCS e intervalo entre tramas según el cálculo recomendado. El tipo 3 es capa 3: cabecera IP más carga, sin depender de VLAN o túneles. Si falta el tipo, la interpretación obligatoria es capa 2.

El tipo 0 es informativo. Un receptor no debe usarlo en interfaces, shapers, policers ni AQM. Los tipos reservados o desconocidos hacen que se descarte toda la opción, porque aplicar un número sin saber qué cuenta puede producir una configuración errónea. Un subcódigo desconocido, en cambio, se ignora sin perder el resto. Si se repite un subcódigo, gana el último.

Estas reglas demuestran que la semántica no cabe en el número. A 1 Gbit/s de L2 le corresponde menos carga útil IP que a 1 Gbit/s de L3. Un test de velocidad y un shaper pueden ser coherentes aun cuando sus cifras no coincidan. La interfaz de usuario debe mostrar la capa y el valor efectivo, no solo una etiqueta comercial.

También hay dos ceros. Una tasa cero significa retirar el límite anterior y volver al comportamiento predeterminado; no es una medición de enlace muerto. Rate Type cero significa que una tasa no se aplica. Perder esa diferencia deja controles huérfanos o transforma telemetría en mandato.

La autoridad depende del tipo de mensaje

En DHCPv4, el cliente puede pedir la opción en la PRL e incluir una sugerencia de máximo o de capa en DHCPREQUEST. El servidor puede ignorarla. La respuesta aplicable llega en DHCPACK. DHCPOFFER puede orientar la elección entre servidores, pero no autoriza a tocar la interfaz.

En DHCPv6, ORO declara interés, Request puede sugerir y REPLY entrega la respuesta. ADVERTISE no debe configurar el equipo. RECONFIGURE puede pedir al cliente que renueve antes del temporizador T1.

El servidor obtiene la tasa de una configuración local, AAA/RADIUS o un motor de política externo. Un relay DHCPv4, como un BNG, puede añadir, cambiar o eliminar OPTION_RATE. De ahí una distinción importante: el servidor puede ser autoritativo para el comportamiento que el borrador exige al cliente, y aun así transportar un dato desactualizado o inadecuado para el plano de reenvío.

RFC 2131 y RFC 8415 delimitan los estados de DHCP. RFC 3046 aporta el contexto de la información de relay, mientras RFC 2865 describe RADIUS. Ninguno convierte una política aceptada en un resultado verificado.

En DHCPv6 puede haber varias verdades locales

Los encabezados de relay anidados permiten al servidor enviar una tasa al cliente y otras a relays concretos. El borrador propone incluso que el policer ascendente de un relay tenga algo más de margen que el shaper del CPE. El relay consume su nivel dirigido; no debería husmear la REPLY destinada al cliente.

Una captura que extrae únicamente el número interior pierde la arquitectura. Hay que indexar dirección, nivel de encapsulación, destinatario, principal que fijó el perfil, capa, lease y periodo de vigencia. RFC 6221 explica el relay DHCPv6 ligero citado por el borrador, pero no certifica que un equipo haya aplicado la nueva opción.

La vigencia forma parte del valor

El mismo CPE puede recibir tasas incompatibles por v4 y v6. El borrador recomienda preferir v6 y obliga a recordar de qué protocolo procede la tasa aplicada. Si expira el lease v6 y sigue vivo uno v4, la tasa retenida pasa a considerarse v4 para actualizaciones posteriores. Si no queda v4 válido, se vuelve al valor predeterminado.

Por tanto, una tasa sin adquisición, expiración, protocolo fuente y decisión de precedencia no es reproducible. El dato actual es el resultado de una secuencia, no una propiedad eterna del abonado.

PPPoE añade otra secuencia. OPTION_RATE por DHCP prevalece sobre una tasa incluida en la respuesta de autenticación PPP. Pero la terminación de la sesión PPPoE revoca implícitamente esa tasa; un valor cero válido también la elimina. RFC 2516 proporciona el marco de la sesión. Conservar el control después de la sesión es conservar autoridad sin contexto.

El tope del puerto no es un mapa del camino

Si se señalan 2 Gbit/s a un CPE con puerto WAN de 1 Gbit/s, el borrador recomienda limitar la aplicación al máximo físico. La gestión debería enseñar la cifra original y la limitada y registrar el desajuste.

Eso demuestra que el equipo impuso una barrera local. No demuestra que el enlace entregue 1 Gbit/s ni que ese puerto sea el cuello de botella. Una red PON, una cola de acceso, un BNG, un enlace de tránsito o el servidor remoto pueden ser más lentos. Llamar al resultado tasa_local_efectiva conserva el límite de la prueba; llamarlo «capacidad disponible» lo rompe.

AQM no nace al recibir un entero

El caso de uso es razonable. Cuando el puerto Ethernet supera la tasa del servicio, la cola puede formarse aguas arriba, en un lugar con buffering o descarte poco controlable. Un shaper local con margen adecuado puede trasladar la cola al CPE y permitir que AQM gestione el retardo.

RFC 7567 ofrece recomendaciones para AQM. RFC 9330, RFC 9331 y RFC 9332 describen la arquitectura L4S, la señalización ECN y un AQM DualQ acoplado. Para que funcionen aún hacen falta una cola ubicada correctamente, clasificación, semántica ECN, un algoritmo activo y controles de congestión compatibles.

El propio borrador llama a OPTION_RATE un habilitador y deja el diseño de AQM fuera de alcance. La recepción del número no prueba que se eligió el algoritmo, que el qdisc está en la salida activa, que el margen evita el policer aguas arriba o que bajó la latencia sin perder utilización.

Seguridad: saber quién habló no basta

DHCP suele circular en claro y sin autenticación. Un servidor falso o un atacante en camino puede introducir una tasa baja y estrangular localmente el servicio. Los clientes pueden usar umbrales contra valores absurdos; el máximo físico reduce el efecto de uno excesivamente alto. Son defensas, no procedencia.

Incluso una firma solo demostraría autoría. No probaría que el perfil seguía vigente, que el relay no lo cambió, que el destinatario instaló la cola ni que el usuario obtuvo el efecto. Hay cuatro preguntas: identidad, autorización, ejecución y resultado.

La primacía del código en ejecución sitúa la conducta real por encima de la etiqueta. La especificación inicial mínima favorece una señal estrecha e interoperable sin convertirla en poder central sobre todas las implementaciones. Las capas de realidad impiden confundir símbolo, configuración, mecanismo físico y experiencia.

Un borrador activo no es una base instalada

El Datatracker muestra la revisión 00 como borrador activo del grupo Internet Area, con estatus previsto Informational, publicado el 27 de agosto de 2026 y con caducidad el 28 de febrero de 2027. El historial registra que reemplazó al documento individual. El XML actual, la ficha del predecesor y su revisión 01 permiten comprobar la línea editorial.

No es un RFC y los códigos siguen como TBD. No hay en este expediente prueba de adopción por fabricantes, despliegue, interoperabilidad, mejora medida ni incidente real.

Fuentes