Resumen

  • TUBA proponía mantener TCP, UDP y muchas aplicaciones, pero sustituir IPv4 por CLNP y direcciones NSAP estructuradas.
  • La transición dependía de hosts y DNS, del soporte de los routers, de las aplicaciones que exponían direcciones IPv4 y de quién podía mantener la norma CLNP.

Una promesa acotada

En junio de 1992, Ross Callon publicó RFC 1347, un memorando informativo sobre dos presiones relacionadas: el espacio IPv4 de 32 bits se estrechaba y las tablas de rutas de las redes troncales crecían con rapidez. La propuesta recibió el nombre de TUBA, «TCP and UDP with Bigger Addresses». No ampliaba IP. Cambiaba la capa de red: TCP o UDP funcionarían sobre CLNP, el protocolo de red sin conexión de ISO, y las direcciones NSAP ocuparían el lugar de las direcciones IP.

El nombre destacaba lo que podía seguir igual para una aplicación. El navegador, el correo o la transferencia de archivos podían continuar sobre los transportes conocidos si no dependían de direcciones de 32 bits dentro de sus propios mensajes. Sin embargo, los paquetes que esos transportes enviaban usarían otra capa de red, otro formato y otro espacio de direcciones. Callon defendió CLNP porque ya ofrecía servicio de datagramas y se encontraba en algunas redes troncales y regionales. Aprovechar software e infraestructura existentes parecía reducir el trabajo de inventar, probar y desplegar otro protocolo.

TUBA no exigía migrar todos los sistemas a OSI. Su objetivo era más limitado: retirar IP sin reemplazar TCP o UDP. RFC 1561, publicado como experimental en diciembre de 1993, definió un perfil de CLNP para ese uso. También reconoció que ambos protocolos ofrecían servicios parecidos, pero no idénticos; el perfil debía conservar la semántica que los protocolos de Internet esperaban.

El DNS participaba en la decisión de ruta

RFC 1347 describe una convivencia gradual. Un host actualizado consultaría al DNS y, si obtenía una dirección IPv4, usaría la pila antigua para contactar con un sistema antiguo. Si recibía una dirección NSAP larga para un par actualizado, enviaría TCP o UDP sobre CLNP. El DNS debía incorporar un registro «long-address». Los routers tendrían que encaminar IP y CLNP, en el mismo equipo multiprotocolo o mediante grupos separados. La dirección devuelta indicaba al host qué protocolo de red utilizar; no hacía falta traducir o encapsular cada paquete entre IP y CLNP.

Ese mecanismo permitía avanzar por etapas, pero no eliminaba las dependencias. Un host compatible podía encontrarse dentro de una red que aún solo transportaba IP. Algunos usos de FTP y NFS incluían direcciones IP en los datos de la aplicación; seguir usando TCP no los salvaba de cambiar. Los operadores de DNS, los fabricantes de hosts y los de routers debían coordinarse. Además, un espacio de direcciones mayor no garantiza rutas agregables: la asignación NSAP tenía que reflejar la topología.

El argumento de despliegue de TUBA se apoyaba en la presencia de routers compatibles con CLNP. La revisión de enero de 1995 en RFC 1752 matizó ese argumento. Los revisores veían una presencia importante de routers capaces de CLNP, pero coincidían menos sobre el despliegue de hosts o redes que realmente usaran CLNP. Un router que puede reenviar paquetes es una pieza útil; por sí solo, no demuestra que exista conectividad entre aplicaciones de extremo a extremo.

La reutilización planteó una cuestión de autoridad

La revisión también registró inquietudes sobre el formato y la alineación de cabeceras, el encaminamiento de origen, los mensajes de error y el uso de NSAP para agregar rutas. Resolver parte de esos problemas podía exigir cambios a CLNP. En la comunidad TUBA no había acuerdo sobre quién podía hacerlos: ¿podía el IETF modificar las especificaciones de ISO o debía seguir el proceso de ISO? Esa duda afectaba al mantenimiento, la resolución de errores y el control práctico de una capa crítica.

En enero de 1995, RFC 1752 recomendó el SIPP revisado como base de IPng después de debatir varios candidatos. No presenta a TUBA como un esfuerzo sin legado: atribuye al trabajo de TUBA aportes a la autoconfiguración y a los mecanismos de transición, dentro de una síntesis de varias iniciativas. CLNP no se convirtió en la nueva capa de red de Internet, pero algunas ideas sobre cómo pasar de una pila a otra contribuyeron al resultado.

La posterior Note:64 de Heng Lu sirve aquí como marco retrospectivo, no como prueba histórica: ¿qué reglas comunes son imprescindibles?, ¿qué decisiones pueden conservar los implementadores?, ¿y qué despliegue demuestra adopción? TUBA ilustra por qué reutilizar un protocolo puede ahorrar trabajo sin resolver quién lo mantiene, qué hosts lo soportan ni qué redes lo transportan.

Fuentes