Resumo

  • O IPv6 NUD registra uma afirmação limitada pelo tempo: evidência recente mostrou que o caminho de ida entregava pacotes à camada IP do vizinho. Quando essa evidência envelhece, REACHABLE vira STALE, ainda que nenhum pacote tenha falhado.
  • O RFC 7048 permite manter o endereço de enlace e sondar com mais paciência quando não existe vizinho alternativo. Essa continuidade não autentica o equipamento, não prova propriedade de endereço, autorização ou conclusão da aplicação.

Durante uma oscilação curta de Wi-Fi, três sondas podem falhar antes que o enlace volte. A pilha ainda conhece o endereço de enlace do roteador. Não existe outro roteador para escolher. Apagar a entrada parece uma reação firme, mas não cria uma saída: força nova resolução, acrescenta multicast e descarta a única pista plausível.

Esse é o tipo de situação em que Neighbor Unreachability Detection precisa administrar duas coisas sem confundi-las. Uma é o valor prático do endereço armazenado. Outra é a validade da prova de que o caminho funciona agora. O primeiro pode ser preservado quando a segunda expira.

Erik Nordmark participa da história normativa dessa separação. É um dos quatro autores do RFC 4861, documento Standards Track que define Neighbor Discovery para IPv6. Seu nome aparece primeiro entre os dois autores do RFC 7048, atualização que trata a impaciência da detecção de inacessibilidade. Também é coautor do RFC 3756, análise Informational de confiança e ameaças. A atribuição comprova contribuição a documentos coletivos do IETF; não concede autoria exclusiva, conformidade automática de implementações ou autoridade sobre redes implantadas.

Alcançável para quem, em qual direção e até quando

No RFC 4861, alcançabilidade é uma afirmação vista pelo nó que envia. Deve haver evidência positiva de que o caminho unidirecional de ida entrega pacotes à camada IP do vizinho e que eles são processados ali. No caso de um roteador vizinho, a evidência abrange o encaminhamento exercido como roteador.

Essa formulação exclui várias certezas tentadoras. Não diz que o serviço de aplicação está saudável, que o caminho de retorno é idêntico, que a pessoa ou empresa dona do equipamento foi autenticada ou que uma operação chegou ao resultado final. A prova vale para um próximo salto específico e por um intervalo de frescor.

Uma confirmação pode vir de uma Neighbor Advertisement solicitada em resposta a uma Neighbor Solicitation. Também pode vir de um protocolo superior que forneça indicação adequada de progresso.

Um ACK TCP novo, por exemplo, indica que dados enviados recentemente chegaram ao par remoto. Se o caminho até esse par usa o vizinho do cache, o ACK sustenta a inferência de que o primeiro salto funcionou. Dados novos, não duplicados, podem indicar que ACKs anteriores também progrediram. A pilha pode aproveitar a observação sem gerar uma sonda extra.

Mas o empréstimo entre camadas tem limite. O ACK não autentica o vizinho de enlace, não comprova simetria de rota, não valida o conteúdo e não certifica um resultado comercial. Ele renova apenas a pergunta estreita para a qual oferece evidência: houve progresso recente pelo caminho de ida.

O estado descreve a evidência, não a personalidade do vizinho

INCOMPLETE significa que a resolução ainda não obteve o endereço de enlace. REACHABLE significa que existe confirmação positiva recente. Quando o temporizador vence, a entrada vai para STALE. O endereço não é apagado; a afirmação forte é que deixa de ser sustentável.

O tempo sozinho não faz uma entrada STALE emitir sondas. Se ninguém precisa usá-la, ela pode permanecer silenciosa. O próximo pacote muda o estado para DELAY e segue para o endereço já conhecido. Essa espera dá à camada superior a chance de fornecer nova confirmação.

Sem confirmação, a entrada passa para PROBE. O nó envia Neighbor Solicitations unicast ao endereço de enlace armazenado. Uma Neighbor Advertisement solicitada e válida pode restaurar REACHABLE. No algoritmo básico, esgotar o número de tentativas elimina a entrada e reinicia a determinação de próximo salto ou a resolução.

O modelo separa memória, frescor, demanda e investigação ativa. Um painel que transforma tudo em up ou down perde justamente o motivo pelo qual os estados existem. Até um campo chamado last_seen é ambíguo: viu um anúncio espontâneo, um ACK TCP, uma resposta à sonda ou apenas um pacote de outra direção?

Um recibo útil registra o mecanismo da confirmação, a interface, o vizinho, o endereço de enlace, o estado anterior, a transição e o vencimento. A pergunta “quando vimos alguma coisa?” não substitui “o que essa coisa podia provar?”.

Informação recebida não é confirmação de ida

Router Advertisements e Neighbor Advertisements não solicitadas podem informar a presença de um roteador ou uma mudança de endereço de enlace. São mensagens importantes. Ainda assim, só mostram que algo viajou do vizinho para o receptor. NUD quer saber se os pacotes do receptor chegam ao vizinho na direção de ida.

Por isso o RFC 4861 determina que Router Advertisements e Neighbor Advertisements com o bit Solicited limpo não sejam usadas para confirmar alcançabilidade. Saber onde alguém está não demonstra que a correspondência chega. Ouvir a pessoa não demonstra que ela nos ouve.

Quando uma plataforma atualiza last_reachable_at diante de qualquer anúncio, apaga a direção da prova. Uma mensagem espontânea pode manter o indicador verde enquanto o caminho de ida segue sem confirmação. O registro deve conservar o bit Solicited, origem, destino, alvo, opção de endereço de enlace e a mudança permitida no cache.

“Aprendi algo sobre o vizinho” e “confirmei que o caminho de ida funciona” precisam ser eventos separados. A automação só pode agir com a autoridade do segundo quando o segundo realmente ocorreu.

O RFC 7048 pergunta se existe para onde falhar

O comportamento descrito no RFC 7048 parte de três transmissões aproximadamente separadas por um segundo. Para um host com outro roteador padrão disponível, o prazo curto pode ser excelente: a falha do vizinho atual libera uma alternativa útil.

Sem alternativa, o mesmo prazo converte uma perturbação transitória em trabalho adicional. A exclusão inicia resolução, muitas vezes multicast, e ainda pode resultar no mesmo endereço. O custo aumenta sem mudar a decisão de encaminhamento.

Nessa condição, o RFC 7048 descreve um estado conceitual UNREACHABLE. A entrada e o endereço de enlace podem ser retidos. Pacotes podem continuar seguindo para ele. As Neighbor Solicitations passam a obedecer recuo exponencial e, em algum momento, precisam ser multicast. A troca importa porque o endereço de enlace pode ter mudado; sondar para sempre apenas o endereço antigo nunca descobriria a mudança.

O nome UNREACHABLE não significa que a pilha interrompeu todo envio nem que a aplicação está definitivamente fora do ar. Significa ausência de confirmação depois do processo de sonda. Se uma alternativa real surgir, a entrada não confirmada não deve impedi-la. Certas entradas criadas por Redirect podem ser removidas em vez de preservadas.

Sondar com paciência é uma escolha condicional, não uma virtude universal. Sem saída, preserva uma chance de continuidade. Com uma boa saída, pode atrasar o failover. A política só faz sentido ao lado do conjunto de vizinhos alternativos naquele momento.

REACHABLE não é uma credencial

O RFC 3756 documenta como mensagens Neighbor Discovery forjadas podem alterar caches. Uma falsa Neighbor Advertisement solicitada pode produzir confirmação enganosa, direcionar tráfego a um endereço malicioso ou inexistente e sustentar negação de serviço. A máquina de estados pode obedecer às regras e, ainda assim, trabalhar com uma entrada adversarial.

Logo, REACHABLE não quer dizer autenticado. Um mapeamento entre IPv6 e endereço de enlace tampouco revela, por si, o dono do equipamento, a organização autorizada, o firmware em execução ou a política que admitiu o pacote. Controles de acesso ao enlace, criptografia, inventário e autorização de aplicação são evidências independentes.

O dossiê de incidente deve mantê-las lado a lado. Para NUD: interface, próximo salto, mapeamento, fonte da confirmação, sequência de sondas, alternativas, contexto de segurança e versão de implementação. Para a aplicação: principal autenticado, decisão de autorização, estado do recurso e comprovante do resultado. A resposta de vizinhança não pode preencher os campos da aplicação.

O autor da norma não é o operador do sistema

O perfil público do IETF consultado em 30 de agosto de 2026 lista 25 RFCs e uma função ativa de revisor no Internet of Things Directorate para Nordmark. São metadados sujeitos a mudança. As páginas dos RFCs fixam os grupos de autoria: Thomas Narten, Nordmark, William Simpson e Hesham Soliman no RFC 4861; Nordmark e Igor Gashinsky no RFC 7048; Pekka Nikander, como editor, James Kempf e Nordmark no RFC 3756.

Os dois primeiros são Standards Track. O terceiro é Informational. A distinção evita transformar uma análise de ameaças em mandato e evita confundir consenso publicado com comportamento implantado.

Código em execução precisa mostrar quais transições ocorreram, quais sinais superiores foram aceitos, como alternativas foram avaliadas e o que ficou no log. A norma oferece vocabulário comum e uma referência verificável. Não assume a decisão da equipe que opera cada rede.

Essa fronteira combina com o melhor aspecto do próprio NUD. O protocolo não afirma mais do que consegue observar. Guarda uma pista quando ela ainda pode ajudar, reduz a confiança quando a prova envelhece e pede nova evidência antes de aumentar a afirmação.

Não foi o vizinho que ficou obsoleto. Foi a prova. A diferença impede que continuidade seja confundida com certeza.

Fontes