Resumo

  • O draft-ietf-intarea-dhcp-rate-signaling-00 propõe taxas de subida e descida em 64 bits e um Rate Type que diferencia informação, camada 2 e camada 3. Trata-se de política de serviço, não de medição instantânea da capacidade.
  • O cliente pode sugerir; o servidor responde; um relay pode inserir ou alterar; e o DHCPv6 pode enviar valores diferentes a níveis distintos do caminho. A expressão “veio pelo DHCP” não identifica sozinha quem decidiu nem quem executou.
  • Para chamar a taxa de efetiva, é preciso preservar origem e validade, ler o controle depois da escrita, identificar a fila ativa e observar pacotes, marcações, perdas, atraso e entrega. Cada etapa produz seu próprio comprovante.

Um CPE renova o DHCPv6 e recebe 1.000.000.000 bit/s no sentido de download. A tela passa a mostrar “1 Gbit/s disponível”. O sistema de automação registra que o shaper foi configurado. Ainda assim, quando uma transferência pesada começa, a latência de uma chamada aumenta.

Os fatos podem coexistir. A taxa pode ser o perfil comercial, não uma medição. Pode contar bytes de camada 2, enquanto o teste mostra carga de camada 3. A fila pode ter sido instalada na interface lógica errada. Um BNG pode impor um policer menor. Ou o gargalo pode estar fora da parte do caminho controlada pelo CPE.

É um cenário analítico, não um incidente documentado. A revisão 00 do draft oferece um meio de transportar a intenção operacional. Ela não comprova que a intenção virou mecanismo nem que o mecanismo produziu o efeito.

Três registros escondidos sob a palavra “velocidade”

Uma operação madura separa o que foi vendido, o que foi configurado e o que foi entregue.

Registro Evidência necessária O que continua em aberto
Taxa sinalizada opção bruta, direção, Rate Type, mensagem, transação, lease, servidor ou relay algum dispositivo aplicou o valor?
Controle efetivo dispositivo, interface, fila, algoritmo, modelo de overhead, transação e leitura posterior essa fila é o gargalo real?
Resultado do serviço ECN, drops, tempo em fila, perda, latência e vazão sob carga definida qual autoridade escolheu a política?

A opção DHCP alimenta o primeiro registro para possibilitar o segundo. Apenas tráfego observado escreve o terceiro. Uma coluna genérica chamada bandwidth impede a reconstrução de uma falha e distribui responsabilidade para o lugar errado.

A camada contabilizada faz parte do valor

As taxas direcionais são inteiros de 64 bits em bit/s. O Rate Type define o que entra na conta.

O tipo 2 é camada 2: inclui cabeçalho Ethernet e payload, excluindo FCS e intervalo entre quadros segundo o cálculo recomendado. O tipo 3 é camada 3: cabeçalho IP e payload, sem variar com o número de tags VLAN ou túneis. Na ausência do Rate Type, a interpretação obrigatória é camada 2. O tipo 0 é apenas informativo; não pode alterar interface física, shaper, policer ou AQM.

Portanto, 1 Gbit/s L2 e 1 Gbit/s L3 não oferecem a mesma carga útil à aplicação. Uma medição de velocidade pode ficar abaixo de uma taxa L2 sem contrariá-la. Se a interface esconde o tipo, transforma uma descrição técnica delimitada em promessa ambígua.

Um Rate Type reservado ou desconhecido invalida OPTION_RATE por inteiro. Já um subcódigo desconhecido é ignorado, e o restante continua. Quando o mesmo subcódigo aparece várias vezes, vale a última ocorrência. A trilha deve guardar a decisão de parsing, não apenas o número normalizado.

Zero também depende do campo. Uma taxa direcional zero significa remover o limite anterior e voltar ao padrão; não é uma observação de capacidade nula. Rate Type zero significa “somente informação”. Confundir as duas coisas pode manter uma limitação antiga ou aplicar uma informação que deveria ser apenas exibida.

A autoridade do servidor termina no ato de protocolo

No DHCPv4, o cliente pode pedir a opção na PRL e sugerir uma taxa máxima ou tipo no DHCPREQUEST. O servidor não precisa aceitar a sugestão; a resposta aplicável chega no DHCPACK. Um valor no DHCPOFFER pode ajudar na escolha de servidor, mas não pode mudar a interface.

No DHCPv6, ORO manifesta interesse, Request pode sugerir e REPLY entrega o valor aplicável. ADVERTISE não deve configurar. RECONFIGURE pode provocar Renew ou Information-request antes de T1.

O servidor pode derivar a taxa de perfil local, RADIUS/AAA ou política externa. Um relay DHCPv4, como o BNG, pode incluir, alterar ou retirar OPTION_RATE. Assim, a resposta pode ser autoritativa para o comportamento definido no draft sem ser uma verdade física. Um perfil pode estar desatualizado; um relay pode ter reescrito o conteúdo; o plano de dados pode não corresponder.

RFC 2131 e RFC 8415 delimitam os estados de DHCP. RFC 3046 dá contexto ao relay, e RFC 2865 ao RADIUS. Nenhum deles lê de volta uma fila ou observa a experiência do assinante.

Um REPLY pode carregar ordens para vários pontos

No DHCPv6, a estrutura aninhada de relays permite que o servidor coloque uma taxa para o cliente e valores diferentes em níveis destinados a cada relay. O draft exemplifica um policer de subida do relay ligeiramente maior que o shaper do CPE. Cada relay deve consumir sua cópia dirigida, sem vasculhar passivamente a REPLY do cliente.

Não existe necessariamente uma única “taxa DHCP”. O registro correto combina direção, nível de encapsulamento, destinatário, origem da política, camada, lease e intervalo de validade. RFC 6221 descreve o Lightweight DHCPv6 Relay Agent citado, mas não prova que um equipamento específico consumiu a nova opção ou programou o hardware.

Dual stack transforma o valor em histórico

Se DHCPv4 e DHCPv6 fornecem taxas conflitantes, o draft recomenda preferir v6 e exige que a origem do valor aplicado seja guardada. Quando o lease v6 expira e um lease v4 continua válido, a taxa retida passa a ser tratada como v4 para atualizações futuras. Sem v4 válido, o dispositivo volta ao padrão.

Uma única célula de “taxa atual” não reproduz essa escolha. São necessários IDs de lease, horários de aquisição e expiração, ramo de precedência, substituição e motivo do reset.

Em PPPoE, OPTION_RATE recebido por DHCP prevalece sobre uma taxa na resposta de autenticação PPP. Mas a sessão PPP define o vínculo lógico: uma taxa zero válida remove o controle e o encerramento da sessão o revoga implicitamente. RFC 2516 dá o contexto. Manter a taxa depois da sessão é manter autoridade sem a relação que a sustentava.

O limite físico é proteção local, não descoberta do caminho

Se o servidor anuncia 2 Gbit/s a uma porta WAN de 1 Gbit/s, o draft recomenda limitar shaping, policing ou AQM à capacidade física. A gestão deve mostrar o valor original e o efetivo e registrar a discrepância.

Isso prova apenas que o dispositivo respeitou um teto local conhecido. Não prova que 1 Gbit/s está disponível, nem que a porta é o ponto mais estreito. PON, agregação, BNG, trânsito ou o servidor remoto podem impor um limite menor. O nome honesto é taxa_local_efetiva, não “capacidade disponível”.

AQM depende de uma fila real

A motivação é convincente. Quando a porta do CPE é mais rápida que a taxa contratada, a fila pode se formar em equipamento a montante com buffer profundo ou descarte bruto. Um shaper local ligeiramente abaixo do limite externo pode trazer a fila controlável para o CPE, onde AQM administra o atraso.

RFC 7567 apresenta recomendações de AQM. RFC 9330, RFC 9331 e RFC 9332 tratam da arquitetura L4S, do protocolo ECN e de um AQM DualQ acoplado. Ainda é preciso escolher e posicionar a fila, classificar tráfego, configurar ECN e contar com controles de congestionamento que reajam.

O próprio draft chama a opção de facilitadora e deixa os algoritmos fora de escopo. Um inteiro recebido não escolhe qdisc, não o prende ao egress ativo, não garante margem contra o policer externo e não mostra que a latência caiu sem desperdiçar vazão.

Autenticação prova autoria, não execução

O draft observa que DHCP normalmente é texto claro e não autenticado. Um servidor falso ou adversário no caminho pode injetar taxa baixa e estrangular o cliente. Limiares mínimos e o teto físico mitigam extremos; não estabelecem procedência.

Mesmo uma assinatura provaria primeiro quem emitiu. Não provaria que o perfil era atual, que o relay foi fiel, que o receptor instalou a fila ou que o usuário recebeu o efeito. Identidade, autorização, execução e resultado são quatro comprovantes.

A primazia do código em execução coloca o comportamento acima do rótulo. A especificação inicial mínima recomenda padronizar um núcleo estreito e manter as escolhas futuras locais e substituíveis. As camadas da realidade separam símbolo, configuração, mecanismo físico e efeito observado.

Publicação não é implantação

O Datatracker mostra a revisão 00 como Internet-Draft ativo do grupo Internet Area, com status pretendido Informational, publicado em 27 de agosto de 2026 e expiração em 28 de fevereiro de 2027. O histórico registra a substituição do draft individual. O XML do grupo, o registro do antecessor e a revisão individual 01 permitem conferir a linhagem.

Não é RFC. Os códigos seguem como TBD. As fontes não demonstram suporte de fornecedor, implantação, interoperabilidade, melhoria medida ou incidente real.

Fontes