Resumen

  • draft-ietf-intarea-dhcp-rate-signaling-00 propone opciones para llevar tasas aprovisionadas por DHCPv4 y DHCPv6; el servidor las elige y distintos intermediarios pueden modificarlas o aplicarlas de manera diferente.
  • Un registro de autoridad debe distinguir el plan comercial, el valor anunciado, el tipo L2 o L3, cada reescritura, la configuración efectiva, el límite físico y las pruebas realizadas aparte.

La cifra que aparece sin haber recorrido la red

Un router doméstico puede conocer al instante una cifra que parece describir su conexión. La recibe en una respuesta DHCP, la muestra en pantalla y quizá la utiliza para configurar un limitador. No ha descargado un archivo de prueba, no ha saturado el enlace y no ha observado un cuello de botella. La cifra llegó porque una parte de la red decidió enviarla.

Ese es el propósito de DHCP Explicit Rate Signaling. En muchos accesos, el enlace Ethernet entre el equipo del cliente y un módem u ONT es más rápido que la modalidad contratada. Si el CPE solo ve la velocidad física, puede acumular la cola en el lugar equivocado. La propuesta ofrece tasas explícitas de subida y bajada para que el CPE, los relays y los switches que inspeccionan DHCP puedan acercar shaping, policing o Active Queue Management al límite aprovisionado.

La mejora operativa no altera la naturaleza del dato. La opción no estima capacidad ni verifica rendimiento de extremo a extremo. Transporta una política. El servidor puede obtenerla de su configuración, de RADIUS/AAA o de otro motor externo. Entre el producto vendido y el paquete que llega al hogar existen varias decisiones que una sola cifra no documenta.

También importa el estado normativo. La revisión 00 pasó a ser documento del grupo INTAREA el 27 de agosto de 2026, después de que sus responsables declararan consenso para adoptar el borrador individual. Sigue siendo un Internet-Draft. Datatracker no registra un estatus RFC previsto y los códigos solicitados a la IANA continúan como valores TBD. Adopción significa revisión colectiva, no estandarización terminada ni despliegue demostrado.

Una unidad, varias definiciones

Las tasas se codifican como enteros de 64 bits en bits por segundo. Un subcampo adicional dice qué debe contar el receptor.

El tipo 0 es informativo. Puede alimentar una interfaz o telemetría, pero no debe configurar una interfaz, un shaper, un policer o AQM. El tipo 2 se refiere a la capa 2 y es el valor predeterminado si el campo no aparece. El tipo 3 se refiere a la capa 3: cabecera IP y carga útil. El borrador observa que esta última base es frecuente en las pruebas de velocidad y en la comercialización de los productos.

Por eso dos sistemas pueden ser correctos y enseñar cifras distintas. Un control de capa 2 cuenta elementos que una prueba de capa 3 excluye; etiquetas VLAN y encapsulados cambian la relación. El tipo no es un detalle ornamental. Si el receptor no comprende un tipo fundamental, debe descartar la opción completa y volver a su configuración predeterminada.

El cero tampoco significa necesariamente que no haya servicio. En la propuesta, una tasa cero significa sin restricción y puede ordenar que se retire un límite anterior. «Cero recibido», «opción ausente», «mensaje inválido» y «respuesta no observada» son estados diferentes. Una plataforma que los guarde en el mismo campo elimina la explicación antes de que surja una avería.

El valor puede tener más de un editor

El servidor es la autoridad en el DHCPACK o REPLY final, aunque el cliente haya enviado una capacidad máxima o una preferencia L2/L3. Esa autoridad se refiere a la transacción DHCP. No confirma que el sistema comercial tuviera el contrato correcto ni que el perfil de AAA estuviera actualizado.

Además, el servidor no siempre escribe la última versión. Un relay DHCPv4, incluido un Broadband Network Gateway, puede añadir, cambiar o quitar la opción. Un nodo de capa 2 que haga snooping puede leerla para crear su propia cola. DHCPv6 permite que los encabezados de relay anidados dirijan valores distintos al cliente y a nodos intermedios; cada relay debe atender la instrucción de su propia capa, no inspeccionar el contenido destinado al cliente.

El camino admite así varias tasas válidas a la vez. El router del abonado puede controlar la subida, el relay una cola de acceso y el BNG la bajada. Que las cifras no coincidan no prueba por sí solo una avería. Sí impide que la captura de pantalla de un único dispositivo represente todo el estado de aprovisionamiento.

El tiempo añade otra dimensión. Las renovaciones y los mensajes Reconfigure de DHCPv6 pueden actualizar la tasa durante la sesión. En DHCPv4, un cliente puede usar el dato de una oferta para escoger servidor, pero solo debe aplicar la opción que llega en DHCPACK. Cualquier evidencia que pierda el tipo de mensaje, la transacción, el tiempo de recepción y la caducidad del lease es incompleta.

El límite físico contradice sin invalidar

La propia propuesta contempla una tasa anunciada superior a la velocidad del puerto. Si se comunican 2 Gbps a un CPE con una interfaz de 1 Gbps, el dispositivo debería limitar la configuración efectiva a la capacidad física. También debería mostrar el valor original y el valor reducido y registrar la discrepancia.

Aquí quedan separadas tres magnitudes: lo que la red anunció, lo que el equipo aplicó y lo que la interfaz admite. Una prueba de velocidad produce una cuarta, condicionada por el servidor de prueba, la ruta exterior, la congestión, el transporte, el Wi-Fi y los equipos terminales. Ninguna debería sobrescribir a las demás.

Los desacuerdos de protocolo necesitan el mismo cuidado. Si DHCPv4 y DHCPv6 envían tasas diferentes, el texto prefiere DHCPv6 y pide conservar el protocolo de origen. Cuando se repite el mismo subcampo, gana el último procesado. En PPPoE, la opción DHCP tiene prioridad sobre valores propietarios recibidos en la autenticación PPP; un cero o el cierre de la sesión restaura los valores predeterminados.

Un panel que solo enseñe «tasa configurada» oculta qué candidato perdió, si un relay intervino, por qué hubo un tope o cuándo se activará el reinicio. La resolución de un conflicto también es un hecho que debe quedar disponible.

El expediente de autoridad de la tasa

Para evitar esa pérdida, las implementaciones deberían producir un expediente compacto de autoridad. Es una propuesta editorial de este artículo, no una obligación del borrador.

La cabecera identifica sesión o lease, equipo, interfaz, versión de DHCP, mensaje, transacción, momento de recepción y vencimiento. A continuación conserva, cuando exista, el plan contratado y la fuente de política, junto con las tasas que anunció el servidor y su tipo informativo, L2 o L3.

Cada relay o BNG añade una entrada: tasa recibida, acción realizada, tasa reenviada, destino de la instrucción y control local creado. En DHCPv6 debe constar el encabezado de relay al que pertenecía. Un switch que solo observó no debe aparecer como si hubiera impuesto la política.

El estado efectivo ocupa columnas distintas: valores del shaper, policer y AQM; capacidad de la interfaz; causa de un tope; protocolo que ganó; condición de caducidad o reinicio. Las mediciones se enlazan como observaciones independientes, con método, extremos, duración y hora. Compararlas es válido; hacer pasar una por la otra, no.

Las palabras del interfaz pueden preservar esta arquitectura. «Anunciada» atribuye un mensaje. «Aplicada» atribuye una acción del equipo. «Admitida» describe el hardware. «Contratada» remite al acuerdo. «Medida» exige una prueba. El sustantivo «velocidad» no contiene ninguna de esas garantías.

El origen importa incluso cuando la cifra parece razonable

DHCP se usa con frecuencia sin autenticación del mensaje. El borrador señala que una respuesta falsificada podría introducir una tasa baja y causar denegación de servicio; plantea umbrales de cordura configurados por el operador. Es el análisis de seguridad de sus autores, no la constatación de un incidente.

Un umbral detiene cifras absurdas, pero una falsificación plausible puede cruzarlo. También puede rechazar un cambio comercial legítimo. Por tanto, hay que saber qué sistema estaba autorizado a elegir la tasa, qué relay podía sustituirla y qué responsable puede explicar una desviación.

El registro actual de parámetros BOOTP/DHCP de la IANA no contiene todavía la opción propuesta ni sus nuevos registros de tipos y subopciones. Ese dato solo describe el punto del proceso. No implica rechazo ni garantiza asignación. Una prueba temprana debe registrar el código usado y la revisión exacta para que el experimento sea reproducible.

Hasta dónde llega la prueba

RFC 7567 explica por qué conviene gestionar la cola junto al cuello de botella. RFC 9330 sitúa las colas breves y las señales ECN en la arquitectura L4S. Una tasa aprovisionada con precisión puede ayudar a que esos mecanismos funcionen y mejorar el rendimiento percibido.

El DHCPACK sigue demostrando únicamente que cierta cadena de control entregó cierta orden en cierto momento. Para afirmar cómo funciona el acceso hacen falta la procedencia de la política, las reescrituras, el estado aplicado, los límites físicos y observaciones externas. La cifra puede tener 64 bits; su autoridad sigue teniendo fronteras.

Fuentes