Resumen

  • RFC 1613 exigió una conexión TCP separada para cada circuito virtual X.25. El Logical Channel Number dentro de XOT era arbitrario y no distinguía dos llamadas de igual número recibidas por flujos diferentes.
  • La capa XOT debía entregar la identidad del stream al motor X.25; la interfaz local de salida escribía después su propio LCN. La identidad del circuito estaba en el mapeo, no en un campo portátil.
  • Las facilidades explícitas de control de flujo, los paquetes de alcance local y el montaje especial de PVC preservaron la misma división entre regla común y decisión local.

El choque ocurrió en el índice

A y B abren sesiones XOT hacia C. Ambos paquetes muestran el mismo LCN. Si C usa solo ese número como índice, mezcla dos valores lícitos en sus interfaces de origen dentro de un falso espacio global. La consecuencia puede ser un paquete entregado al estado equivocado o un Clear aplicado a otra llamada.

RFC 1613, cisco Systems X.25 over TCP (XOT), incluye ese ejemplo. Su ficha en RFC Editor la sitúa en mayo de 1994 y la clasifica como Informational, no como Internet Standard. Documenta un método; no acredita adopción universal.

La respuesta fue asignar una conexión TCP a cada virtual circuit. Dentro de XOT, el LCN no tenía significación y podía ser arbitrario. El motor X.25 de C necesitaba saber que los paquetes habían entrado por interfaces lógicas diferentes. La capa XOT debía comunicarle la identidad de cada stream.

No faltaban bits. Faltaba conservar el ámbito en el que el número era válido.

El stream completó el contexto

TCP se creaba antes que el circuito X.25. RFC 1613 fijó TCP 1998 y prohibió datos XOT en el SYN. El registro actual de IANA contiene x25-svc-port en 1998 para TCP y UDP. El asiento coordina un valor; no prueba escucha, titular, conformidad ni tráfico. El RFC describe XOT sobre TCP.

La conexión aporta endpoints y vida útil para separar circuitos, pero no autentica a una persona, autoriza la llamada ni confirma una operación de negocio.

El TCP histórico de RFC 793 entrega octetos ordenados, no límites de paquete X.25. XOT añadió cuatro bytes: Version y Length, ambos de 16 bits. Version debía ser cero; una versión distinta o longitud ilegal cerraba TCP.

Esa delimitación no es la tesis nueva. RFC 1006 ya recuperaba registros TPDU sobre TCP con otra cabecera de cuatro octetos y BTW ha publicado esa historia. En RFC 1613, un paquete puede estar delimitado a la perfección y aun así llegar al circuito incorrecto si se pierde su stream/interfaz.

La salida puso otro número

Al reenviar hacia una interfaz X.25 local, el implementador debía escribir el LCN usado en esa interfaz. El número podía cambiar mientras el circuito pretendido continuaba. Por eso un recibo serio enlaza conexión TCP, interfaz XOT, LCN entrante, interfaz saliente y LCN saliente.

Conservar solo el LCN genera ambigüedad; conservar solo endpoints TCP borra la asignación local. La primacía del código en ejecución limita la afirmación: el estándar define el mínimo común, y configuración, estado y paquetes prueban este mapeo en esta instancia. Nada de ello crea por sí solo identidad o resultado.

Los defaults no sobrevivieron a la diversidad

Una red X.25 podía compartir packet size y window size por defecto. Entre sitios distintos sobre TCP/IP, RFC 1613 exigió que cada Call declarara ambos. Aceptar una llamada incompleta seguía siendo local; si se aceptaba, Call Confirm debía devolver el valor efectivo.

El control de flujo podía ser end-to-end o local. El segundo podía fragmentar o reunir DATA y conservar secuencias distintas por interfaz. Un enlace modulo 128/8 tenía que traducir estado y reducir una ventana excesiva o rechazar la conexión. Un RNR en un sentido no garantizaba detener DATA en el contrario.

TCP fiable no equivalía a ventana compatible, receptor preparado, secuencia correcta ni transacción completada.

Qué control cruza la frontera

Interrupt y Reset conservaron sentido end-to-end. Restart, DTE Reject, Diagnostic y Registration eran locales y no debían cruzar XOT. La encapsulación no volvió portátil todo el plano de control interior.

Los PVC, provisionados sin Call/Clear, requirieron un setup no estándar tras abrir TCP. Se comparaban nombres de interfaz, LCN locales y valores de flujo. Los estados distinguían interfaz ausente o caída, PVC inexistente, configuración o flujo incompatibles. El éxito con cero exigía Reset local; cerrar TCP rompía el PVC. Dos conexiones creadas por una colisión de setup nunca podían transportar datos a la vez.

Un estado Connected describe la máquina, no al cliente ni la utilidad del tráfico.

Límite de evidencia

La sección de seguridad dice que el memo no trata esas cuestiones. No es una garantía. Las fuentes no acreditan autenticación, cifrado, autorización, aislamiento o resistencia a asociaciones falsas.

No probamos una implementación, versión Cisco, operador ni captura. IANA no demuestra servicio activo. Tampoco se establece despliegue actual, prevalencia, incidente, resultado de aplicación o linaje directo hacia un overlay moderno.

La conclusión sólida es menor: un campo puede ser válido sin tener ámbito suficiente para identificar el objeto operativo. RFC 1613 conservó en el stream y la interfaz el límite que no cabía en el número.

Fuentes