Resumo

  • O DHCPv6-PD transfere o uso de um prefixo para o roteador solicitante, mas não descreve a topologia situada atrás dele.
  • O solicitante precisa transformar o lease em subprefixos estáveis e tempos coerentes; o CE deve manter cada lease associado à rota de próximo salto correta.
  • Um recibo da delegação até a rota deve unir o estado do protocolo à evidência de pacotes nos dois sentidos.

O lease está verde, mas a LAN está apagada

Imagine o console de suporte exibindo uma troca IA_PD bem-sucedida. O roteador a jusante recebeu um prefixo, os tempos preferencial e válido diminuem normalmente e nenhum erro DHCPv6 aparece. Mesmo assim, pacotes destinados a um servidor atrás dele desaparecem no equipamento de borda. O CE nunca instalou a rota para o prefixo usando o roteador a jusante como próximo salto, ou retirou a rota cedo demais.

As duas telas podem estar corretas. O DHCPv6 pode manter uma delegação válida enquanto o caminho de encaminhamento continua incompleto. O erro é tratar o sucesso do lease como prova da reserva no pool, da atribuição ao enlace, do anúncio, da programação e da alcançabilidade.

A RFC 8415 define essa fronteira. A delegação serve a situações em que o roteador delegante não conhece a topologia ligada ao solicitante. O servidor escolhe o prefixo e o entrega; o cliente passa a ser responsável. Ele pode subdividi-lo, atribuir sub-redes a interfaces e anunciá-las. Essas decisões vêm depois da delegação e não estão contidas no estado de sucesso do IA_PD.

Uma transferência de responsabilidade limitada pelo tempo

A unidade operacional não é “prefixo presente”, mas identidade do cliente, IAID, prefixo e comprimento, servidor, T1, T2, tempos preferencial e válido e momento da observação. Um Renew pode prolongá-los, mas a RFC 8415 também permite que o servidor mude o conjunto de prefixos ou devolva um prefixo inadequado com tempos zero. O conteúdo exato da resposta importa mais que o indicador verde.

Os tempos têm hierarquia. Endereços e subprefixos derivados não podem ser anunciados com validade restante maior que a do prefixo pai. Caso contrário, a LAN mantém endereços aparentemente utilizáveis depois que a autoridade a montante terminou. Para o usuário, parece uma falha de rota; a causa real é uma fronteira temporal rompida.

A RFC 9818 acrescenta requisitos aos CEs que delegam na LAN. Eles devem aceitar IA_PD nas interfaces internas, alocar a partir do pool disponível e registrar erro de gerenciamento quando o espaço for insuficiente. O prefixo de um enlace não deve mudar sem alteração de política ou topologia. Sobretudo, a tabela local precisa acompanhar dinamicamente os leases e próximos saltos, removendo a rota quando o prefixo é liberado ou expira.

Persistem falhas independentes: bloco a montante pequeno demais, reserva inconsistente, anúncio ausente, lease sem rota, tempos filhos excessivos ou políticas diferentes para ida e volta. Reler apenas o DHCP Reply não resolve nenhuma delas.

Montar o recibo dos dois lados

Do lado delegante, registre servidor, DUID, IAID, prefixo exato, horário, T1/T2, os dois tempos e o tipo de evento: atribuição, Renew, Rebind, Release ou expiração. Do lado solicitante, registre os subprefixos efetivamente atribuídos, enlaces ou roteadores, tempos herdados e a geração de configuração que tomou a decisão.

Depois acrescente a evidência de encaminhamento: rota no CE, próximo salto, interface, instante de instalação, filtro que pode suprimi-la e evento que a remove. A jusante, capture a rota local, os Router Advertisements e a seleção de endereços esperada. Por fim, teste pacotes e serviço em ambas as direções. Um ping originado no CE não cobre DNS, filtragem stateful, escolha do endereço de origem nem retorno assimétrico.

Avalie o recibo na atribuição inicial, na renovação, em mudanças de política ou topologia e na liberação ou expiração. O mesmo texto de prefixo em dois horários não representa necessariamente o mesmo estado operacional.

Não ampliar o escopo

O recibo não transforma DHCPv6 em protocolo de topologia. Ele aproxima evidências de sistemas distintos respeitando as responsabilidades. Também não resolve seleção de origem e política em redes com vários provedores. A RFC 9818 exclui esse cenário por sua complexidade; nele, o operador deve anexar evidência própria de saída, retorno e domínio de falha.

Fontes