Resumo
- A revisão 06 do rascunho do grupo Internet Area para identificação de nós em mensagens ICMP foi apresentada em 28 de setembro de 2026. O documento permanece em avaliação no IESG como Internet-Draft; não é uma RFC aprovada.
- O texto novo trata do identificador de família de endereços, AFI. Os valores 1 e 2 indicam tamanhos conhecidos para IPv4 e IPv6. Outro valor não informa quantos bytes pertencem ao subobjeto de endereço, portanto o receptor deve parar de processar o objeto de identificação de nó.
- O pacote deve ser tratado como se esse objeto não estivesse presente. A regra não exige abandonar a mensagem ICMP inteira: o comprimento externo previsto na RFC 4884 permite continuar até outras extensões.
Quando a identidade deixa de ter contorno
O endereço de origem de uma resposta a traceroute pode não distinguir o equipamento que gerou o erro, especialmente quando a rota IPv4 atravessa nós apenas IPv6. O rascunho sobre Node Identification propõe anexar endereço IP, nome ou ambos. Isso auxilia a investigação operacional; não autentica criptograficamente o emissor.
Na versão 06, o tamanho do campo de endereço depende do AFI: 32 bits para o valor 1, 128 para o valor 2. Um valor que o receptor não reconhece impede saber onde o endereço termina e onde o próximo campo começa. Prosseguir por palpite poderia apresentar um fragmento mal delimitado como identidade válida. O novo parágrafo exige parar justamente no objeto de identificação e considerar esse objeto ausente.
O limite externo continua relevante. A RFC 4884 descreve uma estrutura de extensões ICMP com informação de comprimento; assim, um leitor pode saltar a parte incompreendida e ainda alcançar mensagens de extensão subsequentes. O rascunho também associa futuras alterações de valores e semântica do AFI à RFC 5837. Isso não autoriza interpretar qualquer número desconhecido só porque ele aparece em um registro de famílias.
Uma resposta à revisão, não um relato de incidente
O parágrafo não estava na versão 05. Uma revisão de segurança perguntou como tratar o restante do objeto sem saber o tamanho do endereço; o histórico da versão 06 atribui a mudança a revisões de segurança e transporte. A existência dessa pergunta não prova exploração, falha de fornecedor nem prevalência em redes reais.
O artigo anterior de Daniel Kade sobre a versão 05 examinou a decisão de ativar ou restringir a divulgação do Node ID. A alteração de agora é outra: mesmo que alguém tenha enviado o objeto, o destinatário não recebe autoridade para preencher uma lacuna de formato com suposições.
Fontes
- https://datatracker.ietf.org/doc/draft-ietf-intarea-extended-icmp-nodeid/
- https://www.ietf.org/archive/id/draft-ietf-intarea-extended-icmp-nodeid-06.txt
- https://www.ietf.org/archive/id/draft-ietf-intarea-extended-icmp-nodeid-05.txt
- https://datatracker.ietf.org/doc/review-ietf-intarea-extended-icmp-nodeid-05-secdir-lc-sethi-2026-09-13/
- https://www.rfc-editor.org/rfc/rfc4884.html
- https://www.rfc-editor.org/rfc/rfc5837.html
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

