Resumo
- Na referência da RFC 4861, o limite de sondagens unicast sem resposta levava à exclusão da entrada no Neighbor Cache.
- A RFC 7048 introduziu UNREACHABLE: uma alternativa pode ser escolhida enquanto o endereço de enlace permanece disponível para sondagens multicast com backoff exponencial.
O que a exclusão rápida resolvia — e o que agravava
A detecção de inacessibilidade não interroga continuamente todos os vizinhos. Progresso observado por um protocolo de camada superior ou uma Neighbor Advertisement solicitada pode confirmar o caminho. Quando uma entrada é usada, a sequência normal é REACHABLE, STALE, DELAY e PROBE. Nesta última fase, as Neighbor Solicitations unicast vão para o endereço de enlace armazenado.
Na máquina conceitual da RFC 4861, o número configurado de retransmissões sem resposta encerrava o processo com a remoção da entrada. A RFC 7048 cita como padrão comum três transmissões, separadas por um segundo. Isso podia acelerar a escolha de outro roteador padrão ou descartar uma entrada criada por Redirect.
Sem vizinho alternativo, porém, remover o registro não oferece outro caminho. O tráfego seguinte precisa refazer a resolução de endereço e pode gerar novas solicitações multicast durante uma falha transitória da camada 2.
Um estado que não promete alcance
A RFC 7048 substitui a exclusão imediata por UNREACHABLE. O nó aumenta o tempo de retransmissão e envia uma Neighbor Solicitation multicast. A entrada comum conserva o endereço de enlace, e pacotes IPv6 ainda podem ser enviados para ele. Isso não significa que o vizinho esteja alcançável: para a seleção do próximo salto, ele não é considerado “conhecido como alcançável”, e uma alternativa pode ganhar preferência.
Entradas criadas por Redirect têm outra continuidade. Podem ser excluídas e não devem ser usadas para transmissão enquanto estiverem UNREACHABLE. A coleta de lixo também continua autorizada; conservar a informação não exige mantê-la indefinidamente.
Mais alcance, menos insistência
Mesmo que algumas sondagens iniciais sejam unicast, a implementação deve mudar para multicast dentro de 60 segundos da retransmissão inicial. Assim, um vizinho que tenha mudado seu endereço de enlace ainda pode responder. Retransmissões além dos limites iniciais devem usar backoff exponencial, limitado por um valor razoável, como 60 segundos. Sem tráfego usando a entrada, elas devem parar até que o uso recomece ou a entrada seja coletada.
Os temporizadores exemplificados pela RFC 7048 mostram uma política possível, não um cronograma obrigatório. A RFC 6583 acrescenta o contexto operacional: resolver enormes quantidades de endereços não atribuídos pode pressionar filas e caches de Neighbor Discovery, mas o documento não define a transição para UNREACHABLE.
A mudança histórica foi separar “não escolher este vizinho agora” de “destruir o último mapeamento”.
Fontes
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
