Resumo

  • draft-ietf-intarea-dhcp-rate-signaling-00 determina preferência por DHCPv6 quando valores v4 e v6 conflitam e exige que o dispositivo retenha o protocolo de origem junto do rate aplicado.
  • Quando um lease expira, até dígitos idênticos podem adquirir outra autoridade; dashboards devem separar valor, fonte, prazo, mutação, limite físico e estado efetivo.

Um roteador aplicou 500 Mbit/s a partir de uma resposta DHCPv6. Horas depois, o lease v6 expirou; o lease DHCPv4 ainda válido também carregava 500 Mbit/s. Para o usuário e para um gráfico de uma coluna, nada mudou. Para a auditoria, quase tudo mudou: servidor, transação, cadeia de relays, período de validade e talvez controles de confiança.

O novo DHCP Rate Option proposto pela INTAREA torna essa diferença explícita. Ele carrega rates de upstream e downstream e um tipo que distingue contagem de camada 2 e camada 3. O propósito é ajudar CPEs, relays e switches com DHCP snooping a posicionar shaping e AQM quando a porta física é mais rápida que o serviço provisionado.

A revisão 00 é um Internet-Draft Informational de 27 de agosto de 2026, com expiração em 28 de fevereiro de 2027. Não é RFC, obrigação de implementação nem inventário de adoção. Os códigos pedidos ainda participam do processo de padronização.

O protocolo de origem integra o valor

Em dual stack, a proposta prefere DHCPv6 diante de informações divergentes. Isso não autoriza armazenar apenas o número vencedor. O dispositivo deve saber de qual protocolo veio o rate que instalou.

Quando a validade v6 termina, o rate v4 pode assumir. Se não houver lease v4 válido, a configuração deve voltar ao padrão local. Em PPPoE, um rate DHCP prevalece sobre o recebido na resposta de autenticação PPP, mas o término da sessão também revoga a configuração.

Essas regras mostram que validade não é metadado decorativo. Ela define se a instrução ainda pode agir. Um valor correto ontem não é uma concessão permanente hoje.

O zero merece registro semântico próprio. Nos suboptions de rate, zero significa sem restrição ou retirada do limitador anterior, com retorno ao padrão. Não significa link medido em zero. Uma plataforma que mistura sinal de controle e observação de capacidade produz um incidente falso justamente quando o equipamento executou uma remoção válida.

Uma oferta escolhe servidor, não reconfigura interface

O cliente pode usar o rate de DHCPOFFER ou ADVERTISE na escolha de servidor, mas só deve aplicá-lo depois de DHCPACK ou REPLY. Ver e executar são estados distintos.

O log “500 Mbit/s recebidos” não basta. É preciso saber a mensagem, se o servidor selecionado repetiu o valor, se um relay o mudou e qual lease sustentava a ação. Preservar a transição evita promover uma pista de seleção a mandato operacional.

O cliente também pode sugerir rates ou preferência de camada. O servidor pode aceitar, rejeitar ou transformar. O pedido do cliente prova uma proposta, não o plano comercial nem o que foi finalmente imposto.

O relay pode trocar a verdade em trânsito

No DHCPv4, um relay pode ler a opção e configurar seu próprio shaper ou policer. Pode ainda adicionar, modificar ou remover a opção depois de consultar RADIUS ou outra fonte AAA. A utilidade operacional é clara; a consequência probatória também deveria ser.

Saída do servidor e entrada do cliente passam a ser registros diferentes. O recibo de transformação deve guardar relay, sessão, versão AAA, valor anterior e posterior, direção, tipo, alvo, razão e validade. RFC 3046 e RFC 2865 dão contexto ao relay e ao AAA, mas não provam a autorização de uma alteração particular.

Em DHCPv6, o servidor pode colocar opções distintas no REPLY do cliente e nas camadas RELAY-REPL. Um relay precisa consumir a opção da sua própria camada, não buscar no payload interno um rate conveniente. Ter custódia do pacote não confere autoridade sobre todas as instruções dentro dele.

A interpretação pode invalidar números bem formados

Camada 2 e camada 3 contam coisas diferentes. Instalar 500 Mbit/s sob o tipo errado pode deslocar o gargalo. Por isso, uma suboption desconhecida pode ser ignorada para permitir evolução, mas um valor desconhecido em campo conhecido e essencial, como rate type, invalida a opção inteira.

Campos repetidos preservam ordem e o último é processado. Transformá-los em conjunto não ordenado destrói a reprodução da decisão. O lease também pode ser aceito enquanto somente a política de rate é rejeitada. “DHCP funcionou” não demonstra “o rate foi aplicado”.

Essa disciplina segue a ideia de especificação mínima de Heng Lu: a camada comum padroniza o mínimo interoperável e deixa decisões futuras próximas de quem opera. Direção, tipo, alvo, estado de mensagem, prioridade e fallback cabem no padrão; veracidade do cadastro e qualidade do resultado não cabem.

O observador que programa fila virou autoridade operacional

Um switch de snooping que converte a opção em fila, shaper ou policer de hardware não é mais mero observador. Precisa provar por que tinha direito de agir: domínio de confiança da porta, vínculo de sessão, nível de encapsulamento, alvo, capacidade da interface, teto local, commit e leitura posterior.

Um pacote capturado prova presença do campo, não o sucesso da configuração nem seu destinatário. Da mesma forma, um rate acima da capacidade física pode ser corretamente sinalizado e corretamente limitado pelo CPE. Sinalizado, interpretado e efetivo são estados diferentes.

Texto claro permite uma ordem hostil perfeitamente válida

DHCP frequentemente não tem autenticação. Um servidor rogue ou atacante on-path pode injetar rate baixo e limitar o assinante sem derrubar o endereçamento. Limite mínimo rejeita alguns extremos; teto físico contém valores altos. Nenhum autentica a origem.

RFC 3118 descreve autenticação DHCP, mas citar a norma não prova deployment. O operador precisa verificar allow-list de servidores, portas confiáveis, validação de relay, proteção de snooping, binding de sessão e autoridade da origem AAA.

O draft observa que gateway rogue, DNS manipulado ou exaustão de endereços podem ser ataques ainda piores. Isso não torna a manipulação de rate inofensiva. Uma ordem baixa pode manter o control plane verde e tornar o serviço inútil.

A fila instalada ainda não é o benefício

Saber o gargalo pode melhorar shaping e AQM. RFC 7567 explica o custo de filas excessivas; RFC 9330 descreve filas rasas no L4S. A recepção do option, porém, não comprova menor latência.

É preciso observar configuração efetiva, ocupação, marcações, drops, distribuição de latência, throughput, erros e rollback. O sinal é intenção; o commit é ação; o resultado é uma afirmação posterior.

A contribuição duradoura do draft pode ser justamente estreita: um vocabulário para transportar rates e regras para quando eles podem agir. Ele não transforma perfil de assinante em fato, relay em canal transparente nem número de política em SLA.

Incerteza

O texto pode mudar, ser substituído ou expirar. Nenhuma implementação de operador, CPE, relay, switch ou firmware específico foi verificada neste trabalho. Ganhos de suporte e desempenho continuam hipóteses a testar no ambiente real.

Fontes