Resumo

  • O draft-ietf-intarea-dhcp-rate-signaling-00 propõe opções DHCPv4 e DHCPv6 para transportar taxas provisionadas; servidores e intermediários podem produzir versões diferentes do valor ao longo do acesso.
  • Um registro de autoridade da taxa deve separar plano contratado, anúncio do servidor, tipo L2/L3, alterações dos relays, controle realmente aplicado, limite físico e medições independentes.

Uma resposta instantânea não é uma medição

Se a tela do roteador mostra “1 Gbps” assim que recebe um DHCPACK, é tentador ler a informação como diagnóstico da linha. O número veio da rede, tem unidade técnica e talvez seja usado para configurar um shaper. Mas não houve fluxo de teste, saturação do enlace nem observação do caminho até um servidor externo.

O rascunho DHCP Explicit Rate Signaling trata de um problema diferente. A conexão Ethernet entre o CPE e um modem ou terminal óptico costuma operar acima da modalidade comprada pelo assinante. Sem conhecer a restrição provisionada, o CPE pode formar a fila depois do verdadeiro gargalo. Levar as taxas de subida e descida pelo DHCP permite que CPEs, relays e switches com DHCP snooping posicionem shaping, policing e Active Queue Management mais perto da limitação.

Isso melhora a capacidade de controle, não a qualidade da evidência sobre desempenho. O servidor pode obter o valor de configuração local, RADIUS/AAA ou um sistema externo de política. O pacote comunica uma escolha feita antes dele. Não descobre a capacidade da linha nem promete que a Internet de ponta a ponta sustentará a mesma taxa.

O estágio do documento também delimita a afirmação. O texto individual entrou em chamada de adoção do INTAREA em 31 de julho de 2026. Em 27 de agosto, os chairs registraram consenso para adotá-lo e pediram que o mesmo conteúdo fosse submetido como revisão 00 do grupo. Ele continua sendo um Internet-Draft sujeito a alteração. O Datatracker não registra status RFC pretendido e os códigos pedidos à IANA ainda são TBD.

O tipo muda o que o número governa

A opção proposta carrega inteiros de 64 bits em bits por segundo para os dois sentidos e um subitem de tipo. A unidade permanece igual, mas a base contábil muda.

O tipo 0 é informativo. Pode abastecer uma tela ou telemetria, porém não deve configurar interface, shaper, policer ou AQM. O tipo 2 é uma taxa de camada 2 e funciona como padrão quando o tipo não aparece. O tipo 3 é de camada 3, limitado ao cabeçalho IP e à carga útil. O rascunho observa que a camada 3 costuma servir à velocidade comercial e aos aplicativos de teste.

Logo, uma fila L2 e um teste L3 podem apresentar diferenças legítimas. Tags VLAN e encapsulamentos estão de um lado e não necessariamente do outro. Um valor informativo, por sua vez, pode representar corretamente o produto e ainda assim não ter autorização para controlar pacotes. Quando o receptor desconhece um tipo fundamental, deve descartar toda a opção e voltar aos padrões, não improvisar uma interpretação.

Zero também é semântico. No desenho, taxa zero quer dizer irrestrita e pode remover um limite anterior. “Zero recebido”, “opção ausente”, “opção inválida” e “resposta não vista” precisam ser estados separados. Reduzi-los a 0 Mbps numa base operacional transforma uma instrução de reset em aparente falha do serviço.

A cadeia de edição atravessa o acesso

No DHCPACK ou REPLY final, o servidor é a autoridade. O cliente pode indicar suporte, sugerir máximos ou preferir L2 ou L3, mas aceita o resultado do servidor. Essa autoridade vale para a transação DHCP; não certifica que o cadastro comercial esteja correto nem que o perfil AAA seja atual.

Depois do servidor ainda pode haver edição. Um relay DHCPv4, inclusive o BNG, pode acrescentar, mudar ou remover a opção. Um nó L2 pode observá-la e criar controles na porta do assinante. No DHCPv6, cabeçalhos relay-reply aninhados permitem direcionar uma taxa ao cliente e outras aos relays intermediários. Cada relay deve atuar sobre a camada destinada a ele, sem vasculhar o conteúdo interno do cliente.

É possível, portanto, haver vários valores válidos no mesmo trajeto. O CPE pode administrar o upload, um relay pode controlar um segmento de acesso e o BNG pode limitar o download. As diferenças não provam erro por si sós. Provam que a tela de um único equipamento não descreve a política inteira.

O instante também interfere. Renovação de lease e Reconfigure no DHCPv6 podem atualizar a taxa durante a sessão. No DHCPv4, a informação de uma oferta pode ajudar na escolha do servidor, mas o cliente só aplica o que está no DHCPACK. Sem tipo de mensagem, transação, horário de recebimento e vencimento, um valor “atual” não tem contexto temporal verificável.

Quando a porta impõe outro teto

O próprio rascunho prevê uma taxa sinalizada maior que a capacidade física. Se chegarem 2 Gbps a um CPE com porta de 1 Gbps, o equipamento deveria limitar shaping, policing ou AQM à capacidade da interface. Também deveria expor o número original e o efetivo, registrando a divergência.

São três fatos: o que a rede anunciou, o que o equipamento aplicou e o que a porta suporta. Um teste de velocidade produz um quarto fato, afetado pelo servidor escolhido, caminho externo, congestionamento, transporte, Wi‑Fi e carga nos dispositivos. Compará-los é útil; substituir um pelo outro elimina justamente a pista que explica a diferença.

Conflitos entre protocolos seguem a mesma lógica. Diante de valores distintos, a proposta prefere DHCPv6 a DHCPv4 e preserva o protocolo de origem da configuração aplicada. Se o mesmo subitem aparece mais de uma vez, vale o último processado. Em PPPoE, a taxa DHCP ganha de parâmetros proprietários trazidos pela autenticação PPP; zero ou encerramento da sessão devolvem o padrão.

Uma coluna final chamada “taxa configurada” não revela quem venceu, qual relay reescreveu ou por que o teto físico foi aplicado. Candidatos rejeitados e critérios de escolha também integram o estado operacional.

Um registro de autoridade para cada taxa

A implementação deveria gerar um registro pequeno e legível para a decisão em vigor. Trata-se de proposta editorial deste artigo, não de requisito do Internet-Draft.

O registro começa com lease ou sessão, equipamento, interface, versão DHCP, mensagem, evidência da transação, horário e validade. Quando disponível, o plano contratado e a fonte da política ficam separados das taxas de subida e descida anunciadas pelo servidor e do tipo informativo, L2 ou L3.

Cada ponto de alteração recebe uma linha: valor de entrada, ação de adicionar, substituir ou remover, valor de saída, identidade do relay ou BNG, destinatário e fila local criada. No DHCPv6, a camada relay-reply precisa ser identificada. Um switch que apenas observou não pode aparecer como executor.

O efeito entra em campos próprios: taxas do shaper, policer e AQM, limite da interface, justificativa do cap, protocolo vencedor e condição de reset. Medições ficam numa série vinculada, com método, pontas e horário. A interface deve usar palavras exatas: anunciado, aplicado, suportado, contratado e medido. A palavra “velocidade”, sozinha, não informa qual dessas relações está em jogo.

Segurança não cabe num filtro de valores absurdos

DHCP frequentemente opera sem autenticação de mensagem. O rascunho avalia que uma resposta forjada poderia injetar uma taxa muito baixa e causar negação de serviço, sugerindo limites de razoabilidade definidos pelo operador. É a análise de ameaça do texto, não o relato de uma ocorrência comprovada.

Um limite barra o absurdo, mas não comprova procedência. Um valor malicioso plausível passa; uma redução legítima pode ser rejeitada. O registro deve dizer qual sistema podia escolher o plano, qual relay tinha permissão para substituí-lo e quem responde por investigar a discrepância.

O registro vigente de parâmetros BOOTP/DHCP da IANA ainda não mostra a opção proposta nem os novos registros de tipos e subopções. Isso registra apenas a fase atual. Não equivale a rejeição nem garante atribuição futura. Testes antecipados precisam guardar versão do rascunho e códigos provisórios para não transformar convenção privada em aparência de padrão.

A fronteira da evidência

A RFC 7567 mostra por que administrar a fila junto ao gargalo é importante. A RFC 9330 explica como o L4S depende de filas rasas e sinais de congestionamento oportunos. Uma taxa provisionada correta pode ajudar esses mecanismos e melhorar a experiência que uma medição posterior captura.

Mesmo assim, a resposta DHCP só prova que uma cadeia autorizada entregou uma instrução naquela transação ou lease. A afirmação de desempenho exige procedência da política, transformações, estado aplicado, limites físicos e observações independentes. A precisão em bits por segundo não concede ao número uma autoridade que seu processo de produção não possui.

Fontes