Resumo

  • A RFC 9928 permite que um 4o6RA encapsule DHCPv4 em DHCPv6 para um cliente IPv4 legado que permanece alheio ao mecanismo.
  • Ao levar essa função para um nó intermediário, a rede pode esconder do servidor DHCPv6 o segmento de camada 2. A combinação back-to-back de 4o6RA e LDRA recupera o Interface-ID, mas a troca interna entre as funções fica fora do escopo.
  • Um lease válido prova que houve alocação e entrega. Sozinho, não prova a porta observada, o mapeamento local do identificador opaco, a regra de pool que venceu nem a ausência de um caminho DHCPv4 direto.
  • Um recibo operacional deve ligar recepção, encapsulamento, ordem dos relays, decisão do servidor, retorno à porta original, detecção de bypass e encerramento do estado.

A compatibilidade desloca a responsabilidade

Em uma rede de acesso, um rádio IPv4 pode depender da porta física para receber o endereço e os parâmetros correspondentes à célula que atende. O dispositivo transmite DHCPv4, recebe DHCPACK e inicia o serviço. Esse resultado parece completo no ponto de vista do cliente. O cliente, porém, não viu a etapa que converteu sua solicitação.

A RFC 7341 definiu DHCP 4o6 com um cliente capaz de transportar DHCPv4 dentro de DHCPv6. Equipamentos que não podem ser atualizados não implementam esse papel. A RFC 9928 permite que o relay assuma a função.

O 4o6RA recebe a mensagem DHCPv4, cria DHCPV4-QUERY e a encaminha pelo domínio IPv6. Quando chega um DHCPV4-RESPONSE válido, ele extrai a resposta DHCPv4 e a entrega ao solicitante. A RFC é explícita: o cliente legado não sabe que está sendo atendido por DHCP 4o6.

Essa ignorância preserva o investimento em equipamento. Também impede que o cliente ateste a rota intermediária. O lease confirma o resultado que recebeu, não a interface escolhida pelo 4o6RA, as camadas de relay ou a origem da informação topológica usada pelo servidor.

O servidor pode decidir pelo local de entrada

Segundo a RFC 7969, a infraestrutura de relay pode fornecer ao servidor informações para escolher endereços e parâmetros com base na topologia. A origem física não é mero detalhe de transporte: pode ser parte do critério de alocação.

No DHCPv4, normalmente só o primeiro relay define giaddr. No DHCPv6, mensagens Relay-forward aninhadas podem formar uma sequência de link-address e Interface-ID. O servidor enxerga a ordem, aplica sua política e devolve Relay-reply pelo caminho inverso.

Quando o DHCP 4o6 sai do cliente e passa a um nó intermediário, o segmento de camada 2 fica antes do ponto onde nasce a consulta DHCPv6. A RFC 9928 afirma que uma solução apenas com 4o6RA não leva informação de interface na mensagem encapsulada e quebra a propagação da topologia.

Ainda assim, o servidor pode responder. Um pool padrão produz endereço sintaticamente correto e, às vezes, serviço parcial. Por isso, disponibilidade e proveniência precisam de métricas diferentes. “Lease ativo” não equivale a “regra de localização corretamente aplicada”.

O LDRA cria uma referência opaca

A arquitetura recomendada combina 4o6RA e Lightweight DHCPv6 Relay Agent. O LDRA obtém o dado da interface voltada ao cliente e inclui Interface-ID no DHCPV4-QUERY.

A RFC 6221 exige a opção em todos os Relay-forward do LDRA. O valor deve permanecer estável para a mesma interface, inclusive após reinício, porque o servidor pode aplicar políticas por correspondência exata.

O valor não descreve publicamente a porta. Ele é opaco. O servidor não deve analisá-lo como se contivesse chassi, slot, porta ou identidade do assinante. O significado operacional está em uma tabela local: naquele instante e naquela geração, o valor correspondia à interface observada.

A RFC 9915 exige que o servidor copie Interface-ID para Relay-reply. O relay usa a opção para selecionar a interface de retorno. Assim, o identificador participa da escolha de parâmetros e da entrega, mas não substitui a prova do mapeamento local.

O elo interno não é definido pelo wire protocol

RFC 9928 deixa fora do escopo o mecanismo que transfere o dado de interface do 4o6RA ao LDRA, o formato dessa informação e até a indicação de que houve participação de 4o6. Implementações podem integrar tudo em um processo ou atravessar hardware de switch, agente e plano de controle.

Interoperabilidade externa não garante, portanto, um histórico interno uniforme. O operador deve registrar quem observou a porta, qual geração converteu a observação no valor opaco, qual versão fez a entrega entre funções e como o sistema reage a dado ausente ou vencido.

Há uma exceção importante: se 4o6RA e servidor DHCP 4o6 estão no mesmo nó, apenas o 4o6RA pode bastar. A recomendação não autoriza exigir LDRA em qualquer desenho. A pergunta correta é se a política recebeu a topologia necessária e se sua origem pode ser revista.

Um bypass também pode parecer saudável

Como o cliente não conhece o mecanismo, mensagens DHCPv4 em broadcast e unicast precisam passar pelo 4o6RA. Um servidor DHCPv4 diretamente alcançável no mesmo domínio de camada 2 pode responder sem o relay. RFC 9928 classifica isso como erro de implantação capaz de causar estado incorreto ou problema de alcançabilidade, e não como nova preocupação de segurança.

Para a operação, dois caminhos possíveis significam duas fontes de estado. O caminho 4o6 e o servidor direto podem fornecer leases plausíveis, com políticas e prazos diferentes. O cliente não consegue atribuir o resultado.

O recibo precisa registrar também a evidência negativa: o broadcast foi interceptado, o unicast de renovação seguiu o caminho planejado e o servidor direto estava ausente ou bloqueado. Uma captura apenas no endpoint não responde a essas perguntas.

Dez elos para revisar a decisão

O recibo de custódia é uma proposta editorial de controle, não uma nova opção DHCP.

Ele começa pela solicitação observada, transação limitada, horário, equipamento de acesso e porta voltada ao cliente. Depois registra geração do mapeamento, identidade do 4o6RA, interface upstream e evento de encapsulamento. A transferência interna para o LDRA ganha registro próprio, com versão e tratamento de falha.

Em seguida vêm Interface-ID opaco, camada exata no Relay-forward, outros link-address e a ordem necessária à política. O servidor registra regra topológica, pool e parâmetros retornados. A volta liga o Relay-reply aninhado, o desencapsulamento e a entrega à porta original.

O nono elo é o teste de bypass. O décimo encerra com Renew, Rebind, mudança de porta, correção, expiração ou rollback, além da regra de retenção. O objetivo não é fabricar um veredito único, mas preservar fatos que podem ser confrontados.

IETF define o comportamento comum. A equipe de acesso controla porta e tabela; a equipe de relay controla interceptação e encapsulamento; o serviço DHCP controla regra e pool. O cliente legado recebe a configuração, mas não deve ser tratado como principal informado de um caminho que não enxerga.

Fontes