Resumen

  • RFC 1298 obligaba a colocar 0.0.0.0 en agent-addr para un Trap-PDU sobre IPX, aunque RFC 1157 había definido ese campo como la dirección del objeto generador.
  • El gestor debía inferir la fuente con la información de transporte. Por eso mensaje, red IPX, nodo, socket y resolución posterior hacia un agente duradero eran registros diferentes.
  • Packet Type 4 portaba SNMP; las solicitudes usaban el socket 36879 y los traps el 36880, mientras GetResponse regresaba a la dirección y socket de origen observados en la petición.
  • Los doce octetos de IpxTransportAddress y la recomendación de 546 octetos resolvían representación e interoperabilidad, pero no autenticaban un equipo ni probaban evento, recepción, respuesta o efecto.

La pérdida ocurría después de recibir

Una captura podía llegar intacta y aun quedar mutilada durante su conservación. Si el sistema guardaba el PDU pero descartaba los metadatos de ingreso, el contenido seguiría siendo legible: versión, comunidad, tipo de PDU y variables continuarían allí. Lo que no podría recuperarse según RFC 1298 era la fuente de transporte que el mapping mandaba usar para el trap.

Este detalle vuelve insuficiente la pregunta habitual «¿tenemos el mensaje?». Hace falta preguntar si se conserva el mensaje con la envoltura que lo trajo, la interfaz que lo recibió y la hora en que ambos quedaron unidos. La atribución no estaba íntegramente dentro del ASN.1.

El problema opuesto aparece cuando el archivo sí retiene el endpoint y le asigna demasiado significado. Una dirección de red, un nodo y un socket permiten describir el origen observado de un datagrama. No demuestran el nombre permanente del dispositivo, su operador ni la autorización de quien transmitió. Para pasar del paquete a una identidad duradera se necesita otra relación, fechada y comprobable.

RFC 1298 se publicó en marzo de 1992 como mapping Informational de SNMP sobre Internet Packet Exchange. No era un Internet Standard. Su registro histórico explica una decisión de portabilidad entre protocolos; no afirma que un sistema concreto siga usándola.

Por qué el PDU terminó con cuatro ceros

La definición anterior explica la rareza. RFC 1157 decía que agent-addr, dentro del Trap-PDU, era la dirección de red del objeto que generaba el trap. Esa fórmula correspondía a la definición de SNMP orientada a UDP/IP y ofrecía una dirección como parte del propio mensaje.

Al llevar SNMP a IPX, RFC 1298 no intentó apretar la dirección compuesta de ese transporte dentro del campo. Ordenó escribir 0.0.0.0 y dijo al gestor que dedujera la fuente a partir de información suministrada por la capa de transporte. Los ceros eran una instrucción de mapping, no un diagnóstico de procedencia desconocida.

La solución evitaba duplicar en el PDU una sintaxis que ya tenía la envoltura. También hacía depender la atribución de una unión externa. PDU y metadatos de ingreso debían sobrevivir juntos. Si se conservaba únicamente agent-addr, todos los traps IPX descritos por el mapping ofrecerían el mismo valor inútil para distinguir emisores.

Ni siquiera la unión completa probaba la condición anunciada. Un trap es una declaración de gestión producida por software u objeto representado. Recibirla no establece que una interfaz física cayó, un proceso se detuvo o un servicio dejó de responder. La condición requiere sus propios sensores y registros; el resultado de una intervención requiere otros más.

El cartero era un servicio de datagramas

IPX se describía como servicio sin conexión y sin acuse de recibo. El remitente podía entregar un datagrama a la capa de red sin crear una sesión ni obtener por ese hecho una confirmación de la aplicación. La transmisión, el ingreso en una interfaz, el parseo y el uso por el gestor eran etapas separadas.

SNMP viajaba en IPX con Packet Type 4, Packet Exchange Packet. El tipo ayudaba a encaminar e interpretar el paquete dentro de la arquitectura, pero no era una firma. Un paquete del tipo correcto no certificaba qué dispositivo lo produjo ni si su contenido representaba una observación verdadera.

El mapping reservaba dos puertas. GetRequest, GetNextRequest y SetRequest se dirigían al socket 36879, hexadecimal 0x900F. Los mensajes Trap se enviaban al 36880, 0x9010. La diferencia asignaba funciones de entrega: una puerta recibía operaciones solicitadas y la otra notificaciones. Ningún socket era propiedad exclusiva de una identidad.

Esta distinción importa al revisar un paquete inesperado. Llegar a 36880 es compatible con el rol de trap; no demuestra que el remitente sea un agente autorizado. Llegar desde 36879 tampoco convierte al origen en gestor legítimo. Socket, identidad y permiso viven en niveles distintos.

La respuesta heredaba el origen de la pregunta

Para GetResponse, el agente usaba la dirección IPX y el socket desde los que había llegado la solicitud correspondiente. La envoltura de entrada no solo permitía devolver el tráfico: vinculaba el retorno a un origen observado.

Esa regla no convierte toda respuesta enviada a la tupla en respuesta recibida. El identificador de solicitud debe correlacionar pregunta y GetResponse; la observación de salida prueba que el agente transmitió; la observación de entrada en el gestor prueba otra etapa; el resultado del parser y la acción de la aplicación completan otras. Una dirección de retorno calculada no resume la cadena.

También hay que preservar la dirección. En una solicitud, la tupla puede ser origen. En la respuesta, pasa a destino. En un trap, la fuente se infiere desde su envoltura y el destino normal es el socket reservado para notificaciones. Una tabla que guarda solo «IPX address» sin verbo ni dirección crea asociaciones imposibles de auditar.

Una dirección de doce octetos podía parecer un nombre

IpxTransportAddress empaquetaba doce octetos: cuatro para el número de red, seis para la dirección física del nodo y dos para el socket. La representación tenía la precisión necesaria para señalar un endpoint de transporte dentro de ese modelo.

No era, por ello, una identidad de directorio. El componente de red aportaba contexto; el nodo localizaba un participante dentro de él; el socket señalaba un servicio. Un inventario podía asociar temporalmente esa combinación con un equipo, pero la asociación debía declarar fuente, vigencia y confianza. La reutilización de direcciones o un cambio de topología podía volver falsa una equivalencia persistente.

Tampoco los doce octetos aportaban seguridad. RFC 1298 decía expresamente que no discutía cuestiones de seguridad. RFC 1270 hacía la misma reserva. No hay en esos textos base para prometer autenticación, autorización, integridad, confidencialidad o protección contra suplantación.

Por eso una investigación necesita mantener tres expresiones sin sustituirlas: 0.0.0.0 como valor deliberado del campo; red, nodo y socket como endpoint observado; nombre del dispositivo como resolución externa. Si existe autenticación separada, será una cuarta prueba, no una propiedad retrospectiva de las anteriores.

El número 546 era una precaución de camino

RFC 1298 recomendaba aceptar mensajes SNMP de hasta 546 octetos. Indicaba que esa longitud podía pasar por routers que no realizaban fragmentación. Para tamaños superiores pedía conocer el máximo admitido en todo el recorrido, incluidos routers y enlaces de datos subyacentes.

La cifra no medía cada red. Era una base común para reducir sorpresas. Un mensaje menor podía perderse por otras razones; uno mayor podía funcionar en un camino conocido. Sin una observación de ambos extremos, la longitud no demostraba entrega. Ante fallos, conservar tamaño, ruta conocida e interfaz resulta más informativo que etiquetar automáticamente el payload como inválido.

RFC 1270 situaba esta decisión dentro de un problema más amplio. Los servicios de transporte diferían en tamaño máximo, fragmentación y alcance. UDP era entonces el transporte SNMP estandarizado y la conformidad completa lo requería. UDP/IP ofrecía la interoperabilidad más amplia, aunque un transporte nativo podía resultar razonable en un entorno que no fuese Internet.

La nota del editor de RFC 1298 aconsejaba enérgicamente UDP/IP en lugar de IPX. El propio mapping reconocía que elegir transporte afectaba ubicuidad e interoperabilidad. Adoptar IPX podía acercar la gestión a una red nativa y alejarla de gestores o agentes que solo compartían el camino estandarizado.

Fuentes y límites de la evidencia

Las fuentes son RFC 1157 — A Simple Network Management Protocol (SNMP), RFC 1270 — SNMP Communications Services y RFC 1298 — SNMP over IPX. Definen el campo original, la política de transportes y el mapping IPX. No prueban un agente real, identidad, evento, recepción por la aplicación, respuesta, remediación, seguridad o despliegue presente.