Resumen

  • RFC 2126 conservó TPKT versión 3 para interoperar con RFC 1006, aunque ese número ya no demostraba que ambos extremos entendían Class 2 ni las mismas opciones.
  • La selección de clase, la existencia del segundo canal, el orden entre canales y la entrega durante una desconexión no disruptiva producían recibos diferentes.

La escena más reveladora de RFC 2126 ocurre después de que TCP ha hecho su trabajo inicial. Hay una conexión y llega una confirmación. El problema es que el servicio confirmado no es el solicitado.

Publicado en marzo de 1997, RFC 2126 refinó el transporte ISO sobre TCP para IPv4 e IPv6. Su objetivo incluía proteger la base instalada de RFC 1006. Por eso no cambió la versión 3 de TPKT. Cambiarla habría excluido implementaciones antiguas que exigían ese valor.

La continuidad era real, pero limitada. Class 0 conservaba el servicio heredado. Class 2 añadía desconexión explícita y opciones para datos urgentes. El mismo número exterior podía envolver capacidades distintas.

Una confirmación no siempre era aceptación

Algunas implementaciones RFC 1006 no sabían negociar clase. Un iniciador podía proponer Class 2 sin alternativa y recibir de un par antiguo un CC Class 0. RFC 2126 advertía que debía rechazarlo conforme a ISO 8073.

El caso separaba cuatro registros: versión compatible, clase preferida en CR, clase elegida en CC y decisión del iniciador. Una respuesta bien formada no borraba la incompatibilidad semántica. El error operativo consistía en usar “TCP conectado” como sustituto de “servicio acordado”.

También el campo reservado debía ignorarse al recibirlo para preservar interoperabilidad. No era una señal secreta de capacidad. La compatibilidad exigía que los bits reservados permanecieran precisamente reservados.

El carril independiente podía quedar desordenado

Class 2 permitía que un ED TPDU viajara dentro del canal normal. También podía negociar Forward o Reverse Connection y abrir otro TCP para datos urgentes. El segundo carril evitaba que la congestión del normal lo bloqueara. Debía unir los mismos hosts, pertenecer a una sola Transport Connection y cerrarse con ella.

Esas reglas probaban asignación, no resultado. Para Forward, el RFC no fijaba cuándo abrir el segundo TCP. La negociación no aportaba una hora de establecimiento. Dos sockets tampoco garantizaban un orden común.

RFC 2126 separaba independencia de sincronización. Forward o Reverse resolvía la primera. Expedited Data Acknowledgement o Non-blocking Expedited Data podía resolver la segunda. Elegir independencia sin sincronización relajaba el servicio ISO y no concordaba con ISO 8072.

Por eso una observación de red debía ser modesta: el socket urgente pertenecía a ese transporte y no estaba bloqueado por el normal. No podía concluir por sí sola que los datos llegaron en orden, a tiempo o a la aplicación.

Dos cierres normales imponían obligaciones distintas

En Class 0, la desconexión dependía del cierre TCP y era disruptiva. Class 2 intercambiaba DR y DC y ofrecía Disruptive y Non-Disruptive Disconnect.

En el modo disruptivo, los TPDUs aún en el origen no tenían que enviarse antes del cierre. El motivo DR era normal, 80 hexadecimal. En el no disruptivo, todos los TPDUs ya entregados al proveedor local debían llegar al usuario remoto. El motivo seguía siendo normal; Additional Information 80 marcaba la obligación mayor.

Así, el mismo reason code no definía el contrato completo. Y la aceptación local tampoco era entrega remota. La custodia empezaba en un punto y debía cerrarse con otra evidencia en el extremo distante.

Número asignado no era servicio observado

El documento reservaba TCP 102, pero no lo imponía en toda conexión. IANA todavía registra iso-tsap en 102 y describe Class 0. Es una prueba de coordinación del espacio de números, no de despliegue, escucha activa o soporte Class 2.

La seguridad conservaba el mismo límite. RFC 2126 no trataba problemas nuevos y afirmaba que el mecanismo no era más ni menos seguro que TCP e ISO 8073. Versión, clase y canal no autenticaban una organización ni autorizaban una acción.

La doctrina publicada por Lu Heng ayuda a leer el protocolo sin anacronismo: el código en ejecución delimita lo observable; una especificación mínima no debe absorber decisiones futuras; una declaración simbólica no equivale al resultado que pretende describir.

El legado de RFC 2126 no es que la versión 3 engañara. Es que la compatibilidad redujo lo que esa versión podía probar. Desde entonces hacían falta recibos separados para versión, clase propuesta, clase seleccionada, aceptación, canal urgente, sincronización, custodia y entrega.

Fuentes