Resumo

  • O RFC 9928 permite que um 4o6RA faça a encapsulação DHCPv4-over-DHCPv6 em nome de um cliente IPv4 legado que não pode ser atualizado.
  • Ao assumir esse papel, o relay muda o ponto de observação e pode ocultar a interface de camada 2; transportar a resposta não comprova a política de alocação correta nem a conectividade do cliente.

Uma migração parecia encerrada porque todas as mensagens previstas existiam. O cliente enviou DHCPv4, o equipamento intermediário produziu DHCPV4-QUERY, o servidor respondeu e o conteúdo voltou ao cliente. O que não existia era o vínculo entre a transação e a porta de acesso. A política dependia da topologia, mas a conclusão dependia apenas da resposta.

Essa diferença define o valor e o limite do mecanismo. Um relay pode provar a transformação que executou. Um servidor pode provar a configuração que escolheu com os dados recebidos. Nenhum deles, isoladamente, prova que o servidor recebeu a origem correta, que o cliente instalou o estado sem conflito ou que o caminho de dados ficou utilizável.

O RFC 7341 transporta mensagens DHCPv4 dentro de DHCPv6 para fornecer parâmetros IPv4 através de redes IPv6. A arquitetura original exige que o cliente implemente DHCP 4o6. O RFC 9928 trata de hosts IPv4-only embutidos ou duradouros que não podem receber essa mudança. A função passa a um switch ou roteador intermediário, o 4o6RA.

Para o host, o diálogo continua sendo DHCPv4. Para o RFC 7341, o 4o6RA ocupa o lugar do cliente. Ele seleciona a interface na qual atuará como cliente DHCPv6, encontra servidor ou relay apropriado, obtém configuração IPv6, solicita a opção de endereço do servidor 4o6 e encapsula a mensagem recebida. Na volta, procura a opção DHCPv4, descarta a resposta ausente ou malformada e entrega o conteúdo correto somente quando ele pode de fato ser encaminhado.

O RFC mantém pequeno o contrato comum. Não há novo formato nem nova obrigação para um servidor 4o6 compatível. É possível testar formação, descarte, extração e encaminhamento. Essa precisão é uma vantagem; ela não transforma transporte em uma decisão universal de configuração.

DHCP pode escolher endereço e parâmetros com base no local da rede. O RFC 7969 mostra a assimetria: no DHCPv4, em geral apenas o primeiro relay preenche giaddr, e uma cadeia expõe só parte da topologia; no DHCPv6, link-address e Interface-ID de vários relays podem descrever o percurso até o servidor.

Quando o próprio cliente executa 4o6, o relay DHCPv6 conhece a interface que recebeu a mensagem encapsulada. Ao deslocar a função para um 4o6RA na borda, esse nó se torna o cliente visível no lado DHCPv6. A rede de camada 2 fica atrás dele. O RFC 9928 afirma que uma solução apenas com 4o6RA quebra a propagação de topologia porque a mensagem não leva a interface do segmento escondido.

A recomendação é combinar o 4o6RA com um LDRA do RFC 6221, em estrutura contígua, para inserir Interface-ID na consulta. Mesmo assim, o mecanismo interno que transfere a informação, seu formato e a indicação da presença do 4o6RA estão fora do escopo. A implementação local deve provar esse elo.

Esse recorte segue bem a proposta de Heng Lu para uma especificação inicial mínima. O protocolo compartilhado coordena apenas o necessário para interoperar. Decisões posteriores permanecem com os operadores que implementam, adotam e respondem pelas consequências. O fato de uma associação ser local não a torna opcional para a auditoria; torna obrigatório nomear seu dono e conservar sua procedência.

O desvio de caminho é outro limite operacional. Como o cliente ignora o 4o6RA, todos os pacotes DHCPv4 de broadcast e unicast precisam passar por ele. O RFC menciona posição central e NAT. Se um servidor DHCPv4 convencional continuar alcançável na mesma camada 2, a solicitação pode escapar, criando estado divergente no cliente e nos servidores e possível impacto de alcance. O documento chama isso de erro de implantação, não de nova questão de segurança. Para quem opera, ainda é uma falha a detectar e reverter.

Uma cadeia de prova deve conservar: identificador e hash da solicitação; porta, VLAN ou interface de entrada; interface DHCPv6 escolhida pelo 4o6RA; descoberta do servidor; hashes de query e response; sequência de relays, link-address e Interface-ID; entrada usada pela política; resposta escolhida; validação e decisão de encaminhamento; lease e opções aceitos pelo cliente; observação de conflito; e teste independente de rota, alcance ou serviço.

A responsabilidade acompanha os recibos. A equipe de acesso responde pelo ponto de entrada. A de relay, pela transformação. A de DHCP, pela regra de alocação. A de dispositivo, pelo estado instalado. A de serviço, pelo efeito. Mesmo dentro da mesma organização, separar essas afirmações reduz o tempo de diagnóstico e impede que uma equipe receba autoridade sobre um fato que nunca observou.

Running-Code Primacy significa dar valor ao que o sistema realmente calculou. Uma query correta é prova da query. A resposta é prova da decisão do servidor diante de suas entradas. O estado bound é prova local do cliente. A sonda é observação datada. A gestão madura não precisa reduzir todos esses fatos à palavra “sucesso”.

Fontes