Resumo
- O RFC 9898 organiza quinze problemas de Neighbor Discovery em três origens: multicast, confiança em todos os nós do enlace e criação de NCE sob demanda pelo roteador.
- REACHABLE confirma alcançabilidade recente segundo o ND. Não confirma propriedade, identidade do assinante, autorização durante todo o incidente nem resultado de aplicação.
O pedido de auditoria parecia simples: identificar quem estava por trás de um endereço IPv6 em determinado intervalo. A equipe de rede apresentou o que tinha à mão — uma entrada REACHABLE com endereço de camada de enlace. A informação provava que o roteador podia encaminhar para aquele vizinho quando a entrada estava válida. Não identificava o titular do contrato.
Essa não é uma falha do Neighbor Discovery. É uma falha de escopo na pergunta. Uma tabela feita para decidir o próximo frame não se torna um cadastro histórico só porque está disponível no mesmo painel da investigação.
O RFC 9898 não cria uma nova solução. Ele reúne problemas conhecidos de ND, antes espalhados por mais de vinte RFCs, e identifica três causas para quinze vulnerabilidades potenciais: uso de multicast, confiança nos participantes do mesmo enlace e Router-NCE-on-Demand. O documento também ressalva que nem todo problema aparece em todo cenário.
No RFC 4861, Neighbor Cache, Destination Cache, Prefix List e Default Router List são estruturas conceituais diferentes. A primeira contém informação de camada de enlace e estado de alcançabilidade de vizinhos; a segunda associa destinos a próximos saltos; a terceira define os prefixos on-link; a quarta mantém roteadores candidatos. Uma implementação pode compartilhar estruturas internas, mas a evidência de uma não assume a semântica das demais.
Quando falta o endereço de camada de enlace do próximo salto, o nó cria uma NCE INCOMPLETE, envia um Neighbor Solicitation multicast e segura o pacote. Um Neighbor Advertisement solicitado e válido pode instalar o endereço, mudar a entrada para REACHABLE e liberar os pacotes. STALE, DELAY e PROBE organizam as verificações seguintes.
São estados de execução. REACHABLE indica confirmação recente do caminho de ida até a camada IP vizinha. STALE guarda a informação de enlace sem confirmação recente. Nenhum campo diz quem contratou, alugou ou recebeu o direito de usar o endereço. A tabela também não promete reter toda transição depois de expiração, descarte ou reinicialização.
O modelo sob demanda transforma o cache em superfície de capacidade. Um remetente remoto pode direcionar pacotes a muitos endereços inexistentes dentro do prefixo on-link. O roteador abre entradas INCOMPLETE e tenta resolver cada alvo, embora o atacante não esteja no enlace. CPU, memória e filas passam a representar perguntas sem resposta.
Por isso, ocupação não é censo. Uma entrada incompleta não comprova a existência de um host. A ausência de entrada também não comprova que o host não estava lá: timeout, garbage collection, limite, reboot ou falta de tráfego recente produzem a mesma fotografia.
O RFC 9898 separa os efeitos. O esgotamento de NCE ameaça o roteador. A resolução reativa acrescenta atraso e perda ao primeiro pacote. A falta de accountability surge porque, com SLAAC, o host forma seus próprios endereços e o roteador talvez só os descubra ao encaminhar. DHCPv6 não entrega automaticamente uma história completa ao roteador sem snooping, registro ou outra ligação com o acesso.
Cada mitigação deve manter seu nome. O RFC 6583 recomenda filtrar espaço sem uso, limitar o processamento de ND e priorizar NCE existentes. Isso protege recursos. Limitar entradas por interface impede crescimento indefinido, mas pode descartar tráfego legítimo se houver mais endereços válidos que capacidade. Não cria identidade.
O RFC 9131 reduz o custo do primeiro pacote: o host pode fazer o first-hop router criar antecipadamente uma entrada STALE. O retorno encontra informação de enlace sem esperar toda a resolução. STALE continua significando informação não confirmada recentemente, não autenticação do usuário.
SAVI vincula endereço a uma porta de camada 2. RA-Guard restringe as portas autorizadas a emitir Router Advertisements. O registro via DHCPv6 comunica ao sistema de gestão endereços autogerados ou estáticos. O RFC 9099 situa ameaças e controles de IPv6. Reunir tudo em um indicador “ND seguro” apaga justamente a proveniência necessária à auditoria.
O padrão comum das soluções é o isolamento. L3+L2 coloca cada host em sua sub-rede e enlace, reduzindo domínio multicast, confiança compartilhada e necessidade de resolução sob demanda. L3-only entrega prefixo único por host ou cliente, ainda que o meio físico possa ser comum. L2 parcial usa proxies para repartir os domínios multicast. Soluções sem isolamento tratam problemas específicos.
A arquitetura mais forte cobra preço. Pode exigir interfaces lógicas, funções novas de roteador, concentrar tráfego e interromper multicast entre hosts. O RFC 8273 alerta que entregar sempre o mesmo prefixo único ao mesmo endereço de enlace facilita rastreamento. O RFC 9663 mostra prefixos por cliente via DHCPv6-PD em redes grandes, mas escalabilidade não substitui uma política de privacidade.
A atribuição robusta junta observadores separados. Guarde a delegação de prefixo, autoridade emissora e validade. Guarde a sessão de acesso, autenticação, circuito, porta ou bearer. Acrescente vínculo SAVI ou registro DHCPv6. Só então conecte a mudança de NCE com interface, endereço IPv6, endereço de enlace, estado, motivo e precisão de relógio. Logs de pacote e aplicação respondem por fronteiras posteriores.
O tempo não é metadado opcional. Um mapeamento consultado depois não prova o mapeamento durante o evento. Privacy addresses, MAC aleatório, reconexão, failover e refresh podem manter um identificador e trocar o sujeito. Se a retenção acabou, a conclusão correta é limite de prova.
A primazia do código em execução de Heng Lu distribui autoridade pela observação direta. O roteador responde pela NCE que executou. O acesso responde pela sessão autenticada. A delegação responde pelo prefixo emitido. A aplicação responde pela transação concluída. Nenhum desses sistemas herda os fatos dos outros por conveniência.
As camadas da realidade impedem que uma representação local ocupe o lugar do objeto completo. A distinção entre controle técnico e soberania prática impede chamar encaminhamento de titularidade. A especificação inicial mínima mantém o ND interoperável e deixa isolamento, orçamento, privacidade, retenção e rollback para quem opera a topologia.
A pergunta de liderança é: qual sistema observou qual relação, por quanto tempo, e que registro independente liga a condição local de encaminhamento ao principal responsável?
Sources
- https://www.rfc-editor.org/rfc/rfc9898.html
- https://www.rfc-editor.org/rfc/rfc4861.html
- https://www.rfc-editor.org/rfc/rfc6583.html
- https://www.rfc-editor.org/rfc/rfc9099.html
- https://www.rfc-editor.org/rfc/rfc9131.html
- https://www.rfc-editor.org/rfc/rfc8273.html
- https://www.rfc-editor.org/rfc/rfc9663.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/on-data-sovereignty-technical-vs-practical-realities/
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

