Resumo

  • O revision 05 propõe anexar endereço IP, nome do nó ou ambos a determinados erros ICMP quando o endereço de resposta não identifica o equipamento de forma suficiente.
  • O Last Call terminou em 22 de setembro de 2026, mas o documento continua sendo um Internet-Draft em avaliação pelo IESG, não um RFC aprovado ou prova de implementação.
  • A função é recomendada desativada por padrão porque nomes podem revelar topologia; o próprio draft informa que não oferece autenticação.

A ambiguidade que aparece como certeza

Em uma rede tradicional, é tentador associar cada endereço de resposta a um roteador. Essa convenção perde força quando vários nós compartilham um endereço IPv4 ou quando uma infraestrutura encaminha rotas IPv4 usando interfaces e próximos saltos somente IPv6. O traceroute observa uma resposta, mas não necessariamente distingue o nó.

O draft de identificação de nó cria um objeto adicional. Ele pode transportar um endereço IPv4 ou IPv6 com escopo adequado ao contexto, um nome humano de até 63 octetos úteis, ou os dois. O endereço externo do ICMP continua existindo. O objeto acrescenta uma alegação sobre a origem interna do erro.

Essa separação precisa sobreviver na ferramenta. “Resposta recebida de X” e “objeto afirma que o nó é Y” são registros relacionados, não sinônimos.

O processo ainda está aberto

O IESG abriu o Last Call em 8 de setembro e recebeu comentários até o dia 22. A captura de 24 de setembro mantém o revision 05 como Active, Submitted to IESG for Publication, Waiting for AD Go-Ahead e IANA OK - Actions Needed. A página pública indica ainda a pauta do telechat de 8 de outubro.

Esses estados documentam a tramitação; não documentam aprovação. O arquivo ainda se declara Internet-Draft e vence em 11 de março de 2027. Mesmo que venha a ser publicado como Proposed Standard, continuariam faltando recibos separados de código, versão, configuração, implantação e benefício observado.

O registro ICMP da IANA já mostra o Class Value 5 como Node Identification Object e aponta para um draft individual anterior. O registro evita colisão de números. Ele não transforma a revisão atual em RFC nem valida um nome recebido.

Um objeto limitado a mensagens específicas

A proposta usa a estrutura do RFC 4884. O novo objeto cabe em ICMPv4 Time Exceeded, Destination Unreachable e Parameter Problem, além de ICMPv6 Time Exceeded e Destination Unreachable.

O endereço pode ter significado apenas local se o operador do domínio souber interpretá-lo. O nome pode vir de sys:hostname ou de outra designação significativa. Ordem, comprimento e preenchimento tornam o objeto analisável. Não tornam seu conteúdo verdadeiro.

O RFC 5837 descreve identificação de interface e próximo salto. O novo draft trata do nó originador. Interface de entrada, interface de saída, próximo salto e nó respondem a perguntas diferentes, e uma investigação deve preservar cada uma.

Os casos de uso aparecem no draft sobre rotas IPv4 com próximo salto IPv6 e no texto sobre XLAT com endereço IPv4 fictício. RFC 7915 e RFC 6877 explicam a tradução IP/ICMP e o 464XLAT. Eles demonstram o contexto técnico, não a adoção do novo objeto.

Um nome resolve e revela ao mesmo tempo

Para a equipe interna, um nome pode identificar cidade, sala, função e posição na malha. Para um destinatário externo, as mesmas palavras expõem a arquitetura. Por isso o revision 05 recomenda manter a inclusão desativada por padrão, salvo o caso específico de tradutores, e permite decisões por endereço de destino e filtragem por ACL.

Uma política responsável escolhe o campo mínimo por grupo de destinatários. Um coletor interno talvez receba nome e endereço. Uma ferramenta de cliente talvez precise apenas de um endereço menos específico. Um host arbitrário na Internet pode não precisar de nenhum. Também é necessário testar nomes truncados e endereços ULA fora de seu domínio de interpretação.

Integridade do formato não é autenticidade

O draft afirma que não define autenticação e que mensagens ICMP são facilmente falsificadas. O checksum da estrutura de RFC 4884 pode indicar corrupção, mas não comprova quem escreveu o campo.

O registro de diagnóstico deve guardar pacote bruto, horário, ponto de observação, sonda original, endereço externo, subobjetos, política esperada e versão do software. Telemetria autenticada, configuração e repetição controlada podem corroborar a alegação, sem apagar a incerteza da observação inicial.

A primazia do código em execução exige evidência da rede real. A especificação inicial mínima e a decisão futura localizada separam o formato comum da decisão local de divulgar. As camadas de realidade impedem que um número de registro substitua implementação, autenticidade e resultado.

Fontes