Resumo

  • A revisão 05 de draft-ietf-intarea-extended-icmp-nodeid foi anunciada em 7 de setembro de 2026 após a análise do diretor de área responsável. O Datatracker registra Last Call Requested, não uma Last Call concluída nem uma RFC.
  • A seção 3 passou a exigir o objeto quando o endereço IP da resposta pode ser insuficiente para identificar o nó, salvo precedência de política local ou segurança. A seção 5 ainda recomenda que o recurso fique desativado por padrão, exceto em tradutores IP/ICMP.
  • São camadas diferentes: primeiro se define o perímetro de divulgação; depois se decide o que fazer com um pacote admitido nesse perímetro. Nenhuma camada autentica o nome enviado.
  • Daniel Kade propõe uma tabela versionada que una configuração, condição, exceção, destino, MTU, bytes emitidos e bytes observados. A proposta é análise editorial, não requisito da IETF.

Uma revisão tornou a condição mais explícita

O anúncio de 7 de setembro apresenta a versão 05 como item de trabalho do Internet Area Working Group. No Datatracker, ela consta como Internet-Draft ativo, enviado ao IESG para publicação, com Proposed Standard como status pretendido e Last Call Requested como estado no IESG. Não há data de telechat. O processo avançou, mas o documento continua sendo trabalho em andamento.

O ponto decisivo veio da análise de Éric Vyncke em outubro de 2025. O diretor de área pediu uma explicação sobre quando seria legítimo não seguir o SHOULD da seção 3. Também questionou o significado de domain, solicitou regras melhores para bits futuros, tratamento básico de MTU e fragmentação e um pedido explícito de registro de subtipos à IANA.

O diff oficial entre 04 e 05 mostra a resposta. A versão anterior recomendava anexar a extensão quando ela fosse necessária para identificar o nó e política ou segurança não prevalecessem. A revisão 05 determina que o objeto seja incluído quando o IP da resposta pode não ser suficiente, exceto se política local ou segurança se sobrepuserem. O texto ainda permite a inclusão incondicional e troca a expressão vaga dentro do domínio por uma noção de escopo apropriado.

O MUST deixa o gatilho mais auditável, mas não elimina julgamento. Alguém ainda define suficiência, reconhece uma exceção e responde pela regra que a autorizou.

Um endereço e um nome não formam um certificado

O Node Identification Object usa a estrutura ICMP multipartes da RFC 4884. Ele pode aparecer em erros selecionados de ICMPv4 e ICMPv6 e carregar um subobjeto de endereço IP, um subobjeto de nome ou ambos. Os bits seguem a organização da RFC 5837, dedicada a interface e próximo salto, para permitir reaproveitamento de código.

O endereço precisa identificar o nó no escopo adequado. Pode ser um IPv6 ULA com sentido apenas local, pois o operador daquele domínio talvez possua o mapa necessário para interpretá-lo. Não há exigência de que todo observador global consiga atribuí-lo.

O nome tem até 63 octetos de conteúdo em um subobjeto preenchido de no máximo 64. Quando apropriado, deve usar o sys:hostname do modelo YANG da RFC 7317, embora outro nome compreensível seja permitido. A revisão 05 acrescenta que o corte no limite deve respeitar a fronteira de um caractere UTF-8.

Isso atende a uma dificuldade operacional real. Em arranjos nos quais rotas IPv4 usam próximos saltos IPv6, um nó intermediário pode não ter um IPv4 próprio para responder a um traceroute IPv4. Um tradutor IP/ICMP pode anexar o endereço de origem anterior à tradução e oferecer ao operador outra chave de correlação.

Correlação não é autenticação. A seção de segurança informa que o rascunho não define mecanismo de autenticação e que mensagens ICMP e seus conteúdos são facilmente falsificados. Um texto parecido com o hostname do inventário continua sendo uma declaração em uma mensagem não autenticada. Um endereço local não prova propriedade, operador, autoridade de rota nem responsabilidade por incidente.

A configuração governa a porta; o MUST, o pacote admitido

A recomendação de desativar por padrão aparece na seção de segurança porque um nome semântico pode revelar função ou estrutura interna. A inclusão deve ser configurável e, fora dos tradutores IP/ICMP, começar desligada. O produto ainda pode usar o endereço de destino e ACLs para decidir quais subobjetos mostrar a cada classe de receptor.

A seção 3 opera depois dessa escolha. Para uma mensagem dentro do âmbito permitido, o objeto torna-se obrigatório quando a resposta comum pode não identificar o nó, a menos que uma regra local de política ou segurança prevaleça. Uma norma abre a capacidade; a outra disciplina seu uso em cada caso.

Essa leitura em dois estágios é a análise deste artigo, não uma decisão oficial de conformidade. O rascunho não transforma suficiente em teste algorítmico, não aponta qual cargo aprova uma exceção e não inclui no pacote um código para explicar a omissão. A mesma resposta vazia pode resultar de decisões opostas.

Ausência não é diagnóstico

Ao receber um Time Exceeded sem Node-ID, o coletor sabe apenas que o objeto não chegou naquele ponto. O endereço comum talvez fosse suficiente; a configuração inicial pode ter sido mantida; uma regra de segurança talvez bloqueie nomes externos; uma ACL pode reservá-los à rede de gestão. O software pode não implementar a versão, ou algum elemento do caminho de volta pode filtrar ou alterar a mensagem.

O tradutor tem mais um ramo normativo. Se o objeto fizer a mensagem exceder a MTU, a revisão 05 recomenda reduzir o campo do datagrama original dentro dos limites da RFC 4884. Se ainda não for possível acomodar o objeto, o tradutor não deve incluí-lo. Para o receptor, essa omissão exigida se parece com uma decisão discricionária de privacidade.

Presença também não encerra a investigação. O formato não prova que o nome veio de sys:hostname, está atualizado, possui correspondência única ou foi emitido pelo aparelho que parece nomear. Plataformas de medição precisam armazenar o valor autodeclarado, a associação posterior ao inventário e qualquer autenticação como evidências distintas.

O registro de parâmetros ICMP da IANA já lista a classe 5 como Node Identification Object e ainda aponta para um rascunho individual mais antigo. A versão 05 solicita um registro de subtipos e deixa os bits futuros sujeitos a Standards Action, conforme a RFC 8126. Governar os códigos impede improvisação incompatível; não garante a origem do valor codificado.

A tabela pode ser pública sem expor a rede

Cada linha da tabela de implementação deveria começar pelo papel do emissor — nó de origem ou tradutor —, família de endereços, tipo ICMP e regra utilizada para considerar suficiente o endereço comum. Em seguida viriam estado da função, versão da política, exceção de segurança e responsável por essa decisão.

Outra parte registraria classe do destino ou ACL, subobjetos autorizados e escopo previsto. A camada do pacote indicaria MTU, redução do datagrama citado, motivo da omissão, bytes realmente enviados e bytes recebidos em posição e horário definidos. A autenticação ficaria em coluna separada: nenhuma neste rascunho, a menos que outro mecanismo tenha sido comprovado.

A versão pública pode empregar nomes sintéticos, hashes de configuração e classes amplas de destinatários. Não é preciso publicar hostnames ou ACLs internos. O que deve sobreviver é a lógica de decisão. Assim, o operador mantém o controle da divulgação, o fornecedor mostra os ramos positivos e negativos e o pesquisador não transforma silêncio em uma conclusão que o pacote nunca carregou.

Fontes