O vizinho não morreu quando o cache virou STALE: como o IPv6 esperou evidência positiva

Resumo

• O Neighbor Unreachability Detection do IPv6 considerava um vizinho alcançável apenas com confirmação positiva recente. Quando ela envelhecia, a entrada ia para STALE, sem ser apagada nem provocar sondas enquanto permanecesse ociosa.
• O primeiro pacote abria DELAY para a camada superior demonstrar progresso. Sem confirmação vinha PROBE; mais tarde, a RFC 7048 criou UNREACHABLE e o recuo exponencial para permitir troca rápida de próximo salto sem abandonar cedo demais o único caminho.

Uma fotografia antiga não era um atestado de óbito

O cache ainda associa o endereço IPv6 do roteador a um endereço de enlace. A última conversa funcionou, mas já faz algum tempo. Não há uma nova mensagem contradizendo a associação nem um alarme físico. Existe apenas a falta de prova recente.

Desde a RFC 1970, de 1996, o IPv6 chamou essa situação de STALE. A RFC 2461 manteve a ideia em 1998, e a RFC 4861 preservou a máquina conceitual em 2007. O estado indica que ReachableTime passou desde a última confirmação positiva do caminho de ida. Não diz que o equipamento desligou.

Enquanto nenhum pacote usa a entrada, nada acontece. Do ponto de vista da correção, informação ociosa pode ficar antiga por tempo indefinido. Coletá-la para liberar memória é uma decisão legítima, mas diferente de concluir que o vizinho falhou. Apagar tudo por relógio só transformaria silêncio em novas resoluções multicast.

A confirmação precisava falar do sentido de envio

Uma Router Advertisement recebida mostra que uma mensagem foi do roteador ao host. Uma Neighbor Advertisement não solicitada também mostra esse sentido. O NUD precisava saber o contrário: pacotes enviados pelo host estavam chegando à camada IP do vizinho?

As especificações aceitaram duas respostas. A primeira era uma Neighbor Advertisement solicitada. O Neighbor Solicitation precisou alcançar o alvo e a resposta precisou voltar. A segunda vinha de um protocolo superior cuja evolução dependia de tráfego anterior ter sido entregue.

No TCP, um ACK novo comprova que dados enviados chegaram ao par. Dados novos e não duplicados podem indicar que ACKs anteriores chegaram ao outro lado. Para destinos fora do enlace, esse avanço implica que o roteador de primeiro salto transportou tráfego recente. UDP e roteadores que apenas encaminham pacotes nem sempre possuem uma pista equivalente; por isso a sonda explícita continuou necessária.

Essa confirmação não autenticava identidade, não prometia disponibilidade futura e não certificava a aplicação. Seu poder era restrito: justificar localmente a continuidade do uso daquela associação em cache.

O pacote de trabalho ganhava cinco segundos para responder

Quando a evidência envelhecia, REACHABLE virava STALE. O próximo pacote ainda saía para o endereço de enlace guardado e mudava a entrada para DELAY. O tempo padrão era de cinco segundos.

DELAY deixava o tráfego comum produzir a prova antes de criar controle adicional. Uma conexão TCP iniciada depois de um período quieto podia avançar quase imediatamente. Se isso acontecesse, a entrada retornava a REACHABLE e nenhuma Neighbor Solicitation era necessária.

Só depois de cinco segundos sem confirmação o nó enviava uma solicitação unicast e entrava em PROBE. A associação ainda era conhecida; a pergunta era se aquele caminho funcionava. Descobrir novamente quem possuía o endereço seria uma pergunta posterior, em multicast.

A ordem economizava sinais. O relógio diminuía confiança. O uso dava importância à dúvida. DELAY esperava um indício que o aplicativo já poderia gerar. PROBE aparecia apenas quando a entrada era antiga, ativa e ainda não confirmada.

Os temporizadores não colocavam todo o enlace no mesmo compasso

A RFC 4861 trazia como padrões uma base de 30 segundos, retransmissão de um segundo, DELAY de cinco segundos e três solicitações unicast. Porém, ReachableTime era sorteado entre 0,5 e 1,5 vezes a base. Router Advertisements também podiam fornecer valores não nulos para base e retransmissão.

A variação evitava que milhares de dispositivos expirassem e testassem vizinhos juntos. Logo, 30 segundos nunca foram um prazo universal de vida.

O roteador podia influenciar os parâmetros, mas sua Advertisement não valia como confirmação. Configurar quanto tempo uma prova permanece fresca e produzir a prova eram poderes separados.

Três tentativas rápidas podiam ser a escolha errada

Na máquina original da RFC 4861, PROBE repetia Neighbor Solicitations unicast e descartava a entrada depois do limite. Com os padrões, eram três transmissões separadas por um segundo. O host podia então tentar outro roteador ou voltar à resolução multicast.

Isso favorecia a recuperação quando havia alternativas. Se o vizinho era o único caminho, uma oscilação de camada 2 mais longa que poucos segundos fazia a entrada sumir sem oferecer rota melhor. O resultado era trocar consultas direcionadas por descoberta multicast em um enlace que já tentava se recompor.

A RFC 6583 mostrou o risco de realimentação. Em um /64, fluxos para muitos endereços inexistentes podiam lotar o processamento NDP. Se a carga expulsasse a manutenção de vizinhos ativos ou as respostas às sondas, entradas válidas seriam removidas, a resolução multicast aumentaria e tráfego estabelecido deixaria de avançar. O documento recomendou priorizar NUD em relação à criação de entradas especulativas.

Em 2014, a RFC 7048 afirmou que o NUD era “impaciente demais”. A atualização introduziu o estado conceitual UNREACHABLE. Depois do limiar, a entrada deixava de ser “conhecidamente alcançável” para a escolha de próximo salto, permitindo testar uma alternativa. Mas o endereço de enlace podia ser mantido, pacotes podiam continuar passando quando necessário e as sondas seguiam com recuo exponencial.

Em algum momento, a sonda precisava virar multicast para encontrar uma mudança no endereço de enlace. Sem pacotes usando a entrada, as retransmissões podiam parar. O exemplo da RFC escalonava tentativas em 1, 4, 13 e 40 segundos e citava 60 segundos como possível teto. Era um algoritmo ilustrativo, não uma descrição de todos os sistemas implantados.

UNREACHABLE mudou a preferência sem encerrar a recuperação

A revisão separou duas decisões que o descarte juntava. Um nó pode deixar de preferir um vizinho assim que a dúvida passa do limite e, ainda assim, continuar tentando recuperar esse vizinho caso ele seja a única saída.

Quando há redundância independente, mudar rápido faz sentido. Quando não há, convergência de spanning tree, perda breve de rádio ou reinício de interface merecem um intervalo maior. O recuo exponencial preserva a chance de retorno sem sustentar uma rajada fixa.

O padrão de evidência não mudou. Progresso da camada superior ou uma resposta solicitada restauravam REACHABLE; anúncios espontâneos continuavam insuficientes. A RFC 7048 consertou a consequência do fracasso, não facilitou a definição de sucesso.

DAD reutilizava pacotes, não a mesma conclusão

A RFC 4862 usa Neighbor Solicitation e Advertisement no Duplicate Address Detection. DAD pergunta, antes da atribuição, se outro nó já usa o endereço ainda tentativo. NUD pergunta, durante o uso, se o caminho associado a uma entrada existente continua funcionando.

Silêncio limitado em DAD pode liberar o endereço para uso. Em NUD, silêncio envelhece a evidência; só o tráfego inicia DELAY e PROBE. A forma da mensagem não amplia o alcance da prova.

Fontes e limites da evidência

A cronologia e os estados vêm das RFCs 1970, 2461 e 4861. A RFC 4862 delimita DAD, a RFC 6583 documenta pressão operacional e a RFC 7048 atualiza a recuperação. Elas não comprovam padrões atuais de fornecedores, participação de implantação, tamanhos de cache, taxas de falha ou conformidade de uma rede específica.