Summary

  • Um Router Advertisement anuncia um roteador e parâmetros. Router Lifetime rege sua utilidade como roteador padrão; opções podem ter vidas independentes.
  • A seleção depende do suporte do host, da preferência e da alcançabilidade. A RFC 4861 separa a detecção de falha em Neighbor Unreachability Detection, não na ausência de anúncios.
  • Um recibo durável deve ligar o RA recebido, a rota realmente escolhida, Neighbor Cache/NUD e pacotes representativos.

A rota apareceu antes de a alcançabilidade ser conhecida

Imagine um host que recebe um RA válido, inclui o emissor como roteador padrão e imediatamente exibe um ::/0 aparentemente saudável. O endereço link-local existe, a vida não é zero e a preferência parece adequada. Mesmo assim, o sentido de ida pode estar quebrado por assimetria, perda do trânsito a montante ou estado de camada 2 obsoleto.

O anúncio não promete o contrário. Router Discovery informa quais roteadores e parâmetros foram anunciados. NUD procura confirmação positiva de que o vizinho recebe e processa pacotes. Confundir as duas perguntas transforma descoberta legítima em garantia de entrega inventada.

Surge um intervalo cego: RA recente e rota instalada antes de progresso de camada superior ou probes NUD confirmarem o primeiro salto. Guardar apenas a instalação apaga a transição decisiva.

O que o Router Advertisement realmente estabelece

A RFC 4861 descreve anúncios de presença do roteador e parâmetros de enlace e Internet: prefixos, hop limit sugerido, Router Lifetime, Reachable Time, Retrans Timer, informação de camada 2 e MTU.

Esses dados não compartilham um relógio. Router Lifetime vale apenas para a utilidade do emissor como roteador padrão; outros campos e opções têm regras próprias. “RA recebido” não reconstrói o que ainda era válido quando um pacote saiu.

A RFC é explícita: a frequência dos anúncios basta para descobrir roteadores, mas não para detectar falha pela ausência deles. NUD cumpre essa função. A idade do último RA multicast não é teste de vida nem confirmação de progresso bidirecional.

A Default Router List aponta para o Neighbor Cache, e a seleção favorece roteadores conhecidos como alcançáveis sobre os suspeitos. O next hop é resultado dinâmico de descoberta, caches e destino, não um significado permanente do anúncio.

Preferência muda a escolha, não comprova entrega

A RFC 4191 adiciona Default Router Preference no cabeçalho e Route Information Option para prefixos mais específicos. Os três valores não são métricas. Com Router Lifetime zero, a preferência do cabeçalho é ignorada. Cada RIO tem prefixo, preferência e vida próprios.

Hosts também diferem. O tipo A ignora preferências e RIO. O tipo B usa preferência de roteador padrão, mas ignora RIO. O tipo C cria tabela com ambos. Para ele, uma RIO ::/0 pode substituir preferência e vida do cabeçalho. Os mesmos bytes podem gerar rotas efetivas distintas.

Alcançabilidade continua primeiro. O tipo B prefere roteadores alcançáveis e só depois a preferência. O tipo C usa maior prefixo, preferência como desempate de comprimentos iguais e ignora next hop conhecido como inalcançável. Sem informação de alcance, o modelo supõe o roteador alcançável. A suposição permite começar a enviar; não prova sucesso.

NUD fornece outra classe de evidência

Neighbor Unreachability Detection busca confirmação positiva de que pacotes chegam ao vizinho e são processados pela camada IP. Progresso recente de camadas superiores pode confirmar. Sem essas pistas, o nó envia Neighbor Solicitations unicast e espera Neighbor Advertisements solicitados.

Neighbor Cache mantém alcançabilidade, número de probes sem resposta e o próximo evento NUD. Uma rota pode continuar instalada enquanto o vizinho passa por reachable, stale, delay e probe. A linha da rota e a do vizinho precisam ser lidas juntas.

NUD ainda é evidência do primeiro salto, não fim a fim. Um roteador pode responder localmente sem rota a montante. A falta momentânea de pista de aplicação também não prova falha. Preserve o escopo de cada observação.

Fontes