Resumen

  • La revisión 05 define un objeto de extensión ICMP con dirección IP y/o nombre de nodo para respuestas cuya dirección de origen no identifica de manera suficiente al equipo.
  • La consulta final del IETF terminó el 22 de septiembre de 2026, pero el texto sigue siendo un Internet-Draft bajo evaluación del IESG, no un RFC aprobado ni una capacidad desplegada.
  • El nombre puede revelar información sensible, la función se recomienda desactivada por defecto y el borrador no incorpora autenticación.

Una dirección compartida produce una conclusión demasiado grande

Un operador lanza traceroute hacia una dirección IPv4. El salto intermedio contesta, pero varios nodos del dominio pueden usar la misma dirección de respuesta. La pantalla ofrece una coordenada; el lector la interpreta como un equipo concreto. Esa diferencia entre coordenada e identidad es el problema que aborda el borrador actual.

La situación no es solo un caso de numeración tradicional. En una red donde las interfaces y los siguientes saltos son IPv6 incluso para rutas IPv4, un nodo puede carecer de una dirección IPv4 exclusiva para presentarse en el diagnóstico. En escenarios de traducción, un router intermedio IPv6 tampoco cabe limpiamente en una respuesta destinada a una herramienta IPv4.

La propuesta permite añadir una dirección con alcance significativo, un nombre de hasta 63 octetos útiles o ambos. Ese dato no borra la dirección de origen del ICMP. La acompaña. Por eso un registro correcto debería conservar las dos afirmaciones: de dónde llegó el paquete y qué nodo dice el objeto que lo originó.

El 22 de septiembre cerró comentarios, no la normalización

El IESG solicitó comentarios finales hasta el 22 de septiembre. La instantánea de Datatracker del 24 de septiembre mantiene la revisión 05 como activa, enviada al IESG, a la espera del visto bueno del director de área y con acciones de IANA. La página pública señala además una teleconferencia del IESG el 8 de octubre.

Son hitos distintos. El cierre de comentarios no es una aprobación. La inclusión en agenda no es un resultado de votación. El documento conserva la etiqueta Internet-Draft y fecha de expiración del 11 de marzo de 2027. Si llegara a RFC con categoría Proposed Standard, aún quedarían por demostrar implementación, valor por defecto, habilitación local, interoperabilidad y resultado operativo.

El registro de parámetros ICMP de IANA ya muestra el valor de clase 5 para Node Identification Object y remite a un borrador individual anterior. El número coordina el formato. No certifica el estado final del texto ni la veracidad de los objetos que viajen con ese número.

El objeto añade contexto dentro de límites concretos

La estructura parte de RFC 4884, que permite adjuntar objetos a determinados errores ICMP. La revisión 05 limita el nuevo objeto a Time Exceeded, Destination Unreachable y Parameter Problem en ICMPv4, y a Time Exceeded y Destination Unreachable en ICMPv6.

La dirección puede ser IPv4 o IPv6 y tener alcance local si ese alcance es útil para el operador del dominio. El nombre puede ser sys:hostname de YANG u otra designación humana. El orden —primero dirección y después nombre— y el relleno permiten analizar los octetos. Ninguna de esas reglas resuelve quién escribió el valor.

RFC 5837 identifica interfaces y siguientes saltos. La nueva propuesta intenta identificar el nodo que origina el error. Una interfaz de entrada, un siguiente salto y un sistema son observaciones diferentes; unirlas en una sola etiqueta empobrecería el diagnóstico.

Los documentos sobre rutas IPv4 mediante un siguiente salto IPv6 y sobre XLAT con dirección IPv4 ficticia muestran por qué existe la brecha. RFC 7915 y RFC 6877 explican la traducción IP/ICMP y 464XLAT. Ninguna de esas referencias es una estadística de adopción del nuevo objeto.

El dato útil también es el dato que expone

El borrador reconoce que un nombre semántico puede revelar ubicación, función o estructura. Por ello hace configurable la adición del objeto y recomienda desactivarla por defecto, salvo el caso de traductores que describe. También permite decidir según el destino de la respuesta y usar listas de control de acceso.

La unidad de política debería ser más fina que “activar identificación”. Un dominio puede autorizar direcciones para herramientas internas y omitir nombres hacia Internet. Puede entregar un nombre de función a un colector autenticado y conservar solo una dirección local para otros receptores. Debe saber qué ocurre si el nombre se trunca, si una ULA sale de su contexto o si un equipo de gestión no coincide con la instancia de reenvío.

El receptor no recibe una garantía criptográfica

La advertencia de seguridad es inequívoca: la extensión no tiene mecanismo de autenticación y el contenido ICMP se falsifica con facilidad. Una suma de comprobación válida demuestra coherencia del bloque, no autoría. Un nombre plausible puede acelerar una investigación correcta o desviar una respuesta a incidentes.

Por eso la captura operativa debe incluir paquete bruto, hora, punto de observación, sonda original, dirección exterior, subobjetos, política esperada y versión de software. Las pruebas posteriores —telemetría de gestión autenticada, configuración, repetición desde otra sonda— no deben sobrescribir la primera observación; deben enlazarse como comprobaciones independientes.

La primacía del código en ejecución exige verificar lo que sucede. La especificación inicial mínima y la decisión futura localizada sitúan la sintaxis común en el centro y la política de revelación en cada operador. Las capas de realidad impiden que una inscripción registral o un campo bien formado declare por sí solo identidad y resultado.

Fuentes