Resumen

  • RFC 1086 permitía pedir al puente una llamada hacia X.25 o registrar una subdirección de escucha que reenviara llamadas a una dirección IP y un puerto TCP.
  • La conexión TCP de registro permanecía abierta como límite temporal. Al cerrarse, liberaba la subdirección; no demostraba identidad, permiso ni salud del servicio de retorno.
  • Cada llamada utilizaba dos conexiones de red distintas. El puente trasladaba TPDU entre X.25 y TCP, pero no convertía ese enlace en prueba del resultado de la aplicación.

El problema no era sólo cruzar redes

La arquitectura partía de una coincidencia: ambos extremos podían usar transport class 0. La RFC 1006 ya explicaba TP0 sobre TCP/IP; X.25 ofrecía el otro soporte. La RFC 1086 añadió un host puente que aplicaba cada método donde correspondía.

El documento no prometía una traducción general entre DDN e ISO. Exigía protocolos ISO superiores a ambos lados y se presentaba como experimento. Un programa TCP cualquiera no adquiría semántica X.25 por pasar por la caja.

La dificultad especial aparecía al recibir. El llamante X.25 necesitaba una subdirección del puente, pero el destino real estaba en un host IP. El espacio disponible era pequeño. Si la reserva sobrevivía indefinidamente al host remoto, acababa siendo una fuga de nombre y capacidad.

La especificación vinculó la escucha a algo que el puente podía observar sin consultar una base externa: la vida de una conexión TCP.

La puerta distinguía dos intenciones

El cliente conectaba al puerto TCP 146 y enviaba un octeto de función. El valor 1 elegía una llamada saliente hacia una dirección X.25. El 2 solicitaba escuchar en una subdirección. Cero era inválido y 3–255 quedaban reservados.

En la función 1, la siguiente pieza era la dirección X.25. El puente intentaba abrir la llamada. Si no podía, cerraba TCP. La negativa no se envolvía en una taxonomía nueva de errores de gateway.

La función 2 tenía más estado. El cliente enviaba una subdirección perteneciente al espacio X.25 del puente y, después, el destino de retorno: IPv4 y puerto TCP. El puente atendía la subdirección. Ante una llamada entrante, abría otra conexión TCP al destino registrado; si fallaba, rechazaba la llamada.

La entrada no decía “este host es dueño”. Decía “mientras dure este registro, intenta emparejar esta entrada X.25 con este retorno TCP”. Su alcance era una instancia de puente y una época operativa.

Un heartbeat sin pulsos

RFC 1086 llamó heartbeat a la conexión original de registro. No definió paquetes periódicos ni comprobaciones de respuesta de la aplicación. La continuidad del socket era el único reloj.

Cuando se cerraba, el puente suponía terminada la escucha. Dejaba de aceptar llamadas para esa subdirección y podía reutilizarla. La regla evitaba que una asignación temporal se volviera eterna por falta de un mensaje final.

Pero ese reloj no era una credencial. Un host no autorizado podía conservar el socket y agotar el espacio. Una caída breve podía desalojar a un host autorizado. Y una conexión perfectamente abierta podía apuntar a un programa bloqueado o a una política ya revocada.

El estado de TCP contestaba si el puente seguía viendo el canal de registro. No contestaba quién estaba al otro lado ni qué debía permitírsele.

Dos conexiones debajo de TP0

Al completar el establecimiento, existían dos conexiones de red. Una llevaba TP0 sobre X.25; la otra, TP0 sobre TCP. El puente leía una TPDU y la escribía en el soporte opuesto. Al desconectarse un lado, cerraba el otro.

La RFC 905 sitúa las unidades y fases de TP0. La RFC 793 describe el TCP histórico que abre, transmite y cierra el lado IP. RFC 1006 aporta el contenedor de TPDU sobre el stream. El registro de RFC 1086 decide cómo nace la pareja; no cambia el significado interno de la aplicación.

Por eso una aparente conversación de transporte contenía dos superficies de fallo. X.25 podía aceptar y TCP rechazar. El canal de registro podía seguir vivo mientras una llamada particular se rompía. El callback podía abrirse y la aplicación negarse después.

Menos errores visibles, más contexto operativo

La especificación evitó crear informes de error propios. Los fallos recuperables de red se ignoraban y los demás acababan en desconexión. Tras el establecimiento, el circuito debía resultar indistinguible del lado RFC 1006.

La transparencia reducía dependencias para los extremos. También impedía que una simple desconexión explicara siempre su causa. El operador necesitaba registrar si la pérdida nació en X.25, en TCP, en una decisión local o en la falta de recursos. Un protocolo pequeño no elimina la información; desplaza parte de ella fuera del protocolo.

La autorización no viajaba en el registro

El texto afirma que autenticación y autorización son asuntos locales. Advierte que, sin restricciones, cualquier host TCP/IP podría reclamar parte del espacio X.25 limitado del puente.

La advertencia impide confundir una dirección con autoridad. IPv4 permite encaminar el callback; no nombra a una persona. El port identifica un punto de transporte; no valida el software. Una subdirección libre puede asignarse bajo una política; no pertenece automáticamente al primer socket.

El operador debía añadir admisión, cuotas, resolución de colisiones y trazabilidad. El octeto de función era una petición. La autorización era una decisión separada y debía conservar su propia evidencia.

Formatos exactos para una época concreta

El registro X.25 ocupaba 68 octetos e incluía dirección X.121, protocol ID, call user data y facilities con longitudes explícitas. El retorno TCP/IP incluía tipo, puerto, IPv4 y relleno. La RFC describe ambos formatos como ad hoc y ligados a UNIX.

Eran coordenadas operativas suficientes para la prueba, no identificadores universales. Un parser podía aceptar todos los campos y aun así recibir una reclamación abusiva.

El registro de IANA conserva iso-tp0 en el puerto 146 y recuerda que una asignación no avala un producto ni garantiza que el tráfico sea el servicio nombrado. Sus filas actuales TCP y UDP tampoco reescriben el pasado: RFC 1086 define su registro mediante TCP.

El estado debe conservar cinco planos

Una investigación necesita la solicitud, la decisión local, la vida del canal de registro, la pareja de conexiones de cada llamada y el resultado de TP0 o de la aplicación. Son cinco hechos, no cinco campos intercambiables.

Un indicador verde para el heartbeat puede coexistir con callbacks fallidos. Una conexión de datos puede ser técnicamente válida y partir de una reserva ilegítima. Un resultado TP0 no equivale al trabajo esperado por el usuario.

La aportación histórica de RFC 1086 no es un ancestro obligatorio de los sistemas modernos. Es una demostración nítida de alcance: una conexión puede ofrecer una caducidad observable para una reserva sin ofrecer identidad, permiso ni verdad sobre la capa superior.

Fuentes y límites

RFC 1086 especifica el puente; RFC 1006, RFC 905 y RFC 793 acotan TP0 y TCP; IANA conserva el registro. Ninguna de esas fuentes prueba despliegue actual, un puente real, titularidad, autenticación, cumplimiento, una llamada concreta o efecto humano.