Resumen

  • El emisor podía activar SRC cuando la dirección FROM de 32 bits servía para devolver un mensaje. Los adaptadores intermedios podían apagar el bit si la dirección no funcionaba como destino en sentido inverso.
  • Si el bit llegaba activo, invertir TO y FROM debía alcanzar el proceso de origen. La garantía no abarcaba la integridad de los datos, la identidad humana, la legitimidad de la dirección IP ni el permiso para ejecutar la solicitud.

RFC 1044, publicada en febrero de 1988, documentó el transporte de IP sobre equipos HYPERchannel. Su trabajo iba más allá de asignar un tipo de trama. Intentaba reconciliar implementaciones existentes de 16 bits, introducir direcciones de 32 bits, separar la dirección del servidor del tipo de mensaje y preparar una evolución desde archivos locales hacia resolución central y, algún día, ARP distribuido.

En medio de esa transición aparece una idea pequeña y precisa: la red podía conservar una afirmación sobre el camino de respuesta sin afirmar que la solicitud merecía confianza.

La dirección de ida llevaba incorporada una posibilidad de respuesta

El formato básico entregaba el mensaje según TO. La dirección FROM no participaba físicamente en esa entrega; viajaba para que el receptor pudiera responder. En general, intercambiar TO y FROM, junto con las máscaras de trunks, permitía devolver un mensaje al origen.

Por eso la dirección ya tenía valor operativo antes de existir el bit SRC. Reducía la información necesaria para construir una respuesta y enlazaba el mensaje con un proceso del soporte. Pero “sé dónde responder” no equivale a “sé quién lo pidió”. Un programa no autorizado también puede ocupar una dirección válida.

El componente lógico de TO escogía el servidor de protocolo final. El campo de tipo podía guiar a equipos intermedios, pero no sustituía esa selección en el destino. RFC 1044 evitaba así que una sola etiqueta pretendiera ser dirección física, selector de servicio y clasificación de tránsito al mismo tiempo.

SRC era una afirmación que el camino podía restar

La extensión de 32 bits añadió GNA, CRC y SRC. El primero señalaba el formato global. El segundo se refería a una comprobación de integridad de los bytes por adaptadores compatibles. El tercero declaraba que la dirección FROM era correcta para el retorno.

El host transmisor iniciaba la afirmación. Si había procurado usar la dirección correspondiente a la interfaz real, activaba SRC. Cada adaptador intermedio podía apagarlo cuando el FROM recibido no fuera una dirección TO capaz de llevar el mensaje inverso al originador.

La ruta no añadía certificados. Solo podía conservar o retirar la afirmación inicial. Esto hace de SRC un mecanismo de evidencia negativa especialmente claro: si desaparece, no se puede sostener la garantía fuerte. Si sobrevive, sabemos que los participantes que aplicaron la regla no detectaron la incompatibilidad definida.

La frase anterior incluye dos límites. Primero, depende de que los equipos aplicaran la regla correctamente. Segundo, el transmisor podía no activar el bit y los equipos antiguos podían no entenderlo. La ausencia no identifica por sí sola un ataque; la presencia tampoco prueba una custodia que no se haya establecido por otros medios.

La garantía terminaba en el proceso de origen

RFC 1044 explica qué significa FROM correcto: al intercambiar las direcciones, la respuesta se entrega al proceso que realmente originó el mensaje. No promete que ese proceso corresponda a un empleado concreto, a un nombre global o a una clave. Mucho menos promete que el contenido de la petición esté permitido.

Un proceso comprometido conserva su capacidad de recibir respuestas. Una configuración equivocada puede ser reversible de forma coherente. Un programa puede pedir una acción prohibida desde la ubicación física esperada. La ruta de retorno aporta continuidad a la conversación; no crea un mandato.

El propio texto condiciona un uso de seguridad más ambicioso a la protección física cuidadosa de adaptadores y enlaces intermedios. Con una topología bajo custodia y una administración responsable, la dirección física puede apoyar una política local. Sin esa custodia demostrada, un bit dentro del mensaje no puede probar que todos los elementos que lo preservaron eran confiables.

La CRC mantenía otro expediente

La separación entre SRC y CRC es deliberada. Algunos adaptadores podían añadir una CRC de 32 bits, conservarla durante el trayecto y comprobarla en el extremo. El resultado daba evidencia contra la corrupción accidental de los bytes a través de equipos y redes intermedias.

Una CRC correcta no demuestra que FROM sea retornable. Un SRC activo no demuestra que el mensaje no haya cambiado. Ninguno autentica a la persona ni concede autoridad a la aplicación. Incluso un mensaje íntegro, reversible y entregado al servidor esperado puede contener una operación fuera de política.

El datagrama de RFC 791 suma su propio conjunto de campos: origen y destino IP, protocolo, longitud total y suma de control de cabecera. HYPERchannel lo contiene, pero no hereda automáticamente el significado de sus direcciones. Comparar la dirección IP con la del soporte ayuda a detectar incoherencias; la coincidencia sigue siendo evidencia de configuración, no identidad.

Resolver no era autenticar

La resolución de direcciones también tenía varias procedencias. RFC 1044 describe la derivación por bits bajos, las tablas locales, un servidor ARP conocido y una futura modalidad distribuida cuando hubiera difusión. La estructura de RFC 826 permitía preguntar qué dirección de enlace correspondía a una dirección de protocolo.

Cada respuesta sirve para construir el encabezado del siguiente salto. No informa por sí sola quién cambió la tabla, si la entrada sigue vigente o si el dueño lógico del servicio autorizó la solicitud. Una asociación equivocada puede devolver respuestas con perfecta regularidad a la máquina equivocada.

SRC actúa después de esa elección. Puede conservar la reversibilidad del resultado, pero no revisar la verdad administrativa del dato que produjo la dirección.

El receptor aún no tenía una política automática

La sección para controladores IP evita convertir el mecanismo en una puerta precipitada. Los transmisores debían activar el bit cuando hubieran hecho el esfuerzo de proporcionar un FROM completamente correcto. Los receptores, sin embargo, no debían tomar ninguna acción particular en ese momento. La especificación reconocía que faltaba decidir qué hacer cuando el bit no llegaba y se sospechaba una violación real o imaginada.

La prudencia protege dos extremos. Rechazar todo mensaje sin SRC puede confundir falta de soporte con hostilidad. Conceder permisos a todo mensaje con SRC puede confundir una ruta reversible con una identidad autorizada. Una política segura necesita conocer capacidades, administrar el perímetro físico y evaluar la consecuencia de la operación.

La aportación histórica de RFC 1044 fue hacer observable una propiedad del soporte y limitar su semántica. La red podía decir “la respuesta vuelve por aquí” sin decir “obedezca lo que llegó por aquí”.

Fuentes y límites de la evidencia

RFC 1044 define los encabezados, la inversión de direcciones, los indicadores, la condición física, la instrucción a los controladores y las etapas de resolución. RFC 791 fija la estructura IP contenida. RFC 826 aporta el modelo de resolución entre protocolo y enlace.

Los documentos prueban lo que se especificó. No demuestran la presencia del mecanismo en una instalación, el comportamiento correcto de cada adaptador, la identidad de un operador, el permiso de una solicitud ni el resultado de una acción.