Resumo

  • A opção 121 do RFC 3442 permitiu que o DHCPv4 entregasse rotas com comprimentos de prefixo explícitos, corrigindo a suposição classful da antiga opção de rota estática.
  • Um cliente compatível precisava instalar essas rotas e priorizá-las em relação às opções Router e 33 quando recebidas juntas; o RFC alertou que um próximo salto incorreto poderia desviar o tráfego.

Uma concessão de endereço parece uma atribuição: a rede informa ao host qual endereço ele pode usar e por quanto tempo. Mas o host também precisa saber para onde enviar pacotes fora do enlace local. O RFC 3442 incorporou essa segunda decisão à conversa de configuração do DHCP. Sua opção de rotas estáticas sem classes podia transportar um prefixo de destino e o endereço do roteador usado para alcançá-lo.

A mudança respondeu a um descompasso. A opção 33 do DHCP, definida no RFC 2132, descrevia rotas estáticas sem uma máscara própria para cada destino. Isso pressupunha que o limite da rede pudesse ser deduzido da classe do endereço. O roteamento sem classes já havia superado essa suposição: 10.0.0.0/8 e 10.0.0.0/24 são destinos diferentes, ainda que compartilhem os primeiros octetos. O cliente precisa do comprimento do prefixo para saber quais bits definem aquela rota.

A opção 121 codificou esse escopo de modo compacto. O descritor do destino começava pelo comprimento do prefixo e carregava apenas os octetos significativos; em seguida vinha um endereço de roteador de quatro octetos. Antes de instalar a rota, o cliente reconstruía o destino e zerava os bits fora da máscara. O RFC 3442 não transformou DHCP em protocolo de roteamento nem distribuiu uma tabela de rotas da Internet. Permitiu que um administrador usasse um servidor já responsável pela configuração dos hosts para instalar rotas estáticas selecionadas nos clientes.

Isso transferiu uma escolha importante entre superfícies administrativas. A tabela de rotas continuou no host, e o cliente continuou aplicando suas regras de processamento. Mesmo assim, uma rota podia passar a se originar na configuração do servidor DHCP em vez de uma edição local em cada dispositivo. Para clientes compatíveis com a opção 121, o RFC exigia instalar as rotas, salvo a exceção de sub-rede local. Se a opção 121 chegasse junto com Router ou com a opção 33, o cliente deveria ignorar os valores antigos. A ordem da solicitação também importava: a opção 121 precisava vir antes de Router e da opção 33 na Parameter Request List.

Compatibilidade fazia parte do desenho. Clientes sem suporte à opção 121 precisavam ignorá-la. Por isso, o RFC 3442 recomendou que administradores também enviassem a opção Router, duplicando a informação do roteador padrão para os clientes antigos. Essa era uma estratégia de transição, não prova de quantos equipamentos suportavam a nova opção nem da velocidade de adoção. Um padrão pode definir precedência; não pode garantir que todo cliente a implemente.

O limite também tinha consequência de segurança. O RFC 3442 alertou expressamente que um endereço de roteador incorreto poderia causar negação de serviço ou desviar o tráfego por um observador. O risco não era exclusivo da opção 121: Router e a antiga opção de rotas também podiam apontar para o próximo salto errado. A opção não provava que a rota proposta estava autorizada, correta ou segura. A autenticação de mensagens, quando usada, era um mecanismo DHCP separado e não bastava para provar que a escolha da rota era sensata.

O tamanho do pacote também condicionava essa entrega. Uma lista longa podia exceder o tamanho tradicional de uma mensagem DHCP, então o RFC 3442 tratou da negociação de mensagens maiores e exigiu suporte à concatenação de opções longas. Em enlaces compartilhados por várias sub-redes IP, também definiu o uso especial do próximo salto 0.0.0.0 para indicar uma sub-rede local diretamente alcançável. Clientes sem o comportamento de pilha necessário precisavam ignorar essa entrada.

A mudança histórica do RFC 3442 foi modesta, mas reveladora: quando o roteamento se tornou sem classes, a configuração de endereços também precisou expressar o escopo das rotas. A concessão passou a poder carregar uma política local de encaminhamento. O cliente continuou sendo o ponto de instalação, mas o administrador DHCP ganhou um papel na escolha de rotas — e o próximo salto passou a ter consequências além da atribuição de um endereço.

Fontes