Resumen

  • La versión 05 de draft-ietf-intarea-extended-icmp-nodeid se anunció el 7 de septiembre de 2026 tras una revisión del director de área. Datatracker indica Last Call Requested; todavía no es una RFC ni una última llamada concluida.
  • La sección 3 ahora exige añadir el objeto cuando la IP de respuesta pueda no bastar para identificar el nodo, salvo que prevalezca la política local o la seguridad. La sección 5 sigue recomendando desactivarlo por defecto, excepto en traductores IP/ICMP.
  • Una norma decide la postura de exposición y la otra la conducta ante un mensaje admitido por esa postura. Ninguna autentica el nombre o la dirección transportados.
  • Daniel Kade propone una tabla versionada que una configuración, condición, excepción, destinatario, MTU, bytes enviados y bytes observados. Es una propuesta editorial, no una regla de la IETF.

Una revisión convirtió la recomendación en condición

El aviso del 7 de septiembre identifica la revisión 05 como trabajo del grupo INTAREA. En el Datatracker figura como Internet-Draft activo, enviado al IESG para publicación, con Proposed Standard como categoría prevista y estado Last Call Requested. No tiene fecha de telechat. El expediente registra avance, no aprobación final.

El cambio principal puede localizarse en la revisión de Éric Vyncke de octubre de 2025. El director de área pidió que se explicara cuándo se podía apartar el SHOULD de la sección 3. También cuestionó el significado de domain, pidió aclarar el procesamiento de bits futuros, tratar MTU y fragmentación y solicitar de forma explícita el registro de subtipos de IANA.

La comparación entre 04 y 05 deja la modificación a la vista. La versión anterior decía que la extensión debería adjuntarse cuando fuera necesaria para identificar el nodo y no prevalecieran la política o la seguridad. La revisión 05 dice que debe añadirse cuando la dirección IP de respuesta pueda no ser suficiente, salvo que esas consideraciones prevalezcan. Además, sustituye el dominio indeterminado por el alcance apropiado y permite incluir el objeto de manera incondicional.

El MUST no elimina la decisión humana. Define mejor el disparador y nombra los dos tipos de excepción. Una prueba seria debe conservar cuál de esos caminos se evaluó.

Dirección y nombre describen; no certifican

El objeto nuevo utiliza la estructura multiparte de RFC 4884. Puede aparecer en determinados errores Time Exceeded, Destination Unreachable y Parameter Problem de ICMPv4, y en Time Exceeded y Destination Unreachable de ICMPv6. La clase 5 puede contener una dirección IP, un nombre o ambos.

La distribución de bits sigue el precedente de RFC 5837, que describe interfaces y siguientes saltos, para que sea posible reutilizar código de generación y análisis. La dirección del nuevo objeto debe ser significativa en el alcance adecuado. Puede ser una dirección IPv6 de ámbito local si el operador del dominio conoce su significado, aunque un observador mundial no pueda resolverla.

El nombre admite hasta 63 octetos de contenido en una estructura rellenada hasta un máximo de 64. Debería corresponder a sys:hostname del modelo YANG de RFC 7317, cuando resulte apropiado, o a otro nombre comprensible. La revisión 05 obliga a no cortar un carácter UTF-8 a la mitad cuando el texto supera el límite.

El caso operativo aparece en redes donde IPv4 viaja sobre infraestructura IPv6. Un router intermedio puede carecer de una IPv4 única con la que contestar a un traceroute IPv4. Un traductor IP/ICMP puede insertar la dirección previa a la traducción, de modo que el operador disponga de una clave adicional para encontrar el nodo.

La clave sigue siendo una afirmación. El propio borrador no especifica autenticación y recuerda que los mensajes ICMP y su contenido pueden falsificarse fácilmente. El parecido entre un nombre recibido y una fila del inventario no demuestra quién emitió el paquete. Una dirección local no acredita propiedad global. La gramática facilita una correlación; no otorga autoridad sobre la ruta ni asigna responsabilidad por una avería.

Dos reglas para dos momentos

La frase «desactivado por defecto» está en la sección de seguridad. La incorporación del objeto es configurable porque un nombre semántico puede revelar función, ubicación o diseño interno. Salvo el caso de los traductores, la configuración debería empezar cerrada. El sistema puede abrirla solo para ciertas direcciones de destino mediante ACL.

El MUST se aplica después, al procesar un mensaje dentro del ámbito permitido. Si la IP ordinaria puede no identificar el nodo, se añade el objeto, excepto cuando una decisión local de política o seguridad lo impide. Un nivel define la puerta; el otro gobierna el tránsito que la atraviesa.

Esa interpretación no sustituye una decisión de la IETF sobre conformidad. El texto no formaliza la prueba de «suficiencia», no identifica al responsable organizativo de la excepción y no incluye un código de ausencia. De ahí que dos dispositivos conformes puedan dejar la misma observación vacía por razones diferentes.

El mismo vacío puede venir de ramas distintas

Un colector que recibe un Time Exceeded sin Node-ID solo conoce el paquete recibido. Quizá la dirección de origen ya era suficiente. Quizá el equipo conserva la configuración inicial. Tal vez una regla de seguridad bloquea todo nombre externo o una ACL reserva la información para sondas de gestión. El software podría no implementar la revisión, o un filtro intermedio podría haber cambiado el resultado.

Para un traductor existe otra posibilidad normativa. Cuando añadir el objeto excedería la MTU, la versión 05 recomienda acortar el datagrama original citado, respetando los mínimos y el redondeo definidos por RFC 4884. Si no cabe aun así, el traductor no debe añadirlo. Desde fuera, esa omisión obligatoria se parece a una denegación de política.

La presencia tampoco resuelve la cadena. El receptor no sabe por la sintaxis si el nombre procede realmente de sys:hostname, si sigue vigente ni si es único. Tampoco hay prueba criptográfica del emisor. Un sistema de medición debe almacenar el valor como etiqueta declarada y mantener aparte la atribución derivada del inventario.

El registro ICMP de IANA ya muestra la clase 5 como Node Identification Object y todavía enlaza una versión individual anterior. La revisión 05 solicita un registro de subtipos y reserva los bits futuros para Standards Action, según RFC 8126. Controlar los códigos futuros mejora la interoperabilidad, no la autenticidad de cada contenido.

Una matriz que pueda reproducir el resultado

La solución de gobernanza es una tabla de decisiones asociada a la versión del producto y de la política. Cada fila debe indicar si emite un nodo original o un traductor, la familia y el tipo ICMP, el criterio que juzga suficiente la dirección común, el estado de la función y la autoridad que aprobó una excepción.

Después deben aparecer la clase de destino, la ACL aplicable, los subobjetos permitidos y su alcance. Una sección de paquete anota la MTU, cualquier reducción del datagrama citado, la causa de omisión, los bytes emitidos y los observados desde un lugar y una hora definidos. La autenticación ocupa su propia columna: ninguna en este borrador, salvo que exista evidencia independiente.

No hace falta publicar nombres internos. Los ensayos pueden usar identificadores sintéticos, huellas de configuración y categorías generales de destinatario. El objetivo no es abrir la red, sino permitir que un resultado se reproduzca sin confundir una política de privacidad con una falla ni una etiqueta visible con una identidad probada.

Fuentes