Resumen

  • RFC 875 distinguió una pasarela de Internet que conservaba el datagrama IP común de una pasarela traductora que debía decidir equivalencias entre direcciones, confirmaciones, control de flujo y opciones incompatibles.
  • Al cerrar una conexión y originar otra, la caja acumulaba estado privado y se convertía en un punto singular para la recuperación, la redundancia y los cambios futuros.

La prueba decisiva de una pasarela no era que el primer carácter apareciera en la pantalla remota. Era saber qué ocurría con el siguiente carácter cuando un extremo pedía detenerse, cuando llegaba una interrupción o cuando la caja desaparecía a mitad de sesión.

En septiembre de 1982, M. A. Padlipsky publicó RFC 875, Gateways, Architectures, and Heffalumps. No especificaba una pasarela para implantar ni medía el número de traductores desplegados. Planteaba una objeción: llamar «gateway» a la frontera entre dos arquitecturas incompatibles ocultaba decisiones que un encaminador ordinario no tenía que tomar.

La diferencia no estaba en la cantidad de programación. Estaba en el objeto compartido. Si ambos lados reconocían el mismo datagrama, el intermediario podía cambiar el envoltorio local y conservar su significado. Si un lado no expresaba la promesa del otro, ninguna operación de formato podía recuperarla.

IP hacía pequeño el acuerdo, no el trabajo

RFC 791 definió IP para interconectar redes de paquetes. Su dirección incorporaba red y host; la fragmentación permitía cruzar redes con tamaños distintos. La entrega fiable, el orden y el control de flujo quedaban expresamente fuera de IP.

Ese límite daba libertad a las redes locales. Una pasarela podía retirar una trama, leer la dirección Internet, seleccionar otro salto y encapsular el mismo datagrama en una tecnología diferente. No necesitaba simular los extremos TCP. RFC 791 incluso indicaba que los protocolos superiores no tenían por qué residir en la pasarela.

RFC 793 situó en TCP, dentro de los hosts, las conexiones, secuencias, ventanas, retransmisiones e indicaciones urgentes. La arquitectura no pretendía que todos los componentes entendieran todas las promesas. Les daba una división verificable de responsabilidades.

Por eso la crítica de Padlipsky no era una defensa de redes homogéneas. IP ya unía redes heterogéneas. Su blanco era la confusión entre heterogeneidad debajo de una capa común e incompatibilidad semántica por encima de ella.

El destino extranjero no cabía en la dirección original

NCP trabajaba con un host dentro del espacio ARPANET. La dirección IP, en cambio, distinguía una red y un host. En la interfaz NCP normal faltaba la dimensión con la que indicar un sistema situado en otra red.

Un traductor podía reservar bits, cambiar el protocolo de conexión inicial o pedir a la aplicación que transportara la dirección Internet. Las tres soluciones introducían una extensión en el lado que supuestamente iba a permanecer intacto. El problema no era convertir una representación numérica, sino añadir una pregunta que ese protocolo no sabía formular.

RFC 875 describió una alternativa honesta: hacer del intermediario un host visible. El usuario establecía una primera conexión, indicaba el destino y la máquina abría una segunda. Padlipsky lo llamó «Janus Host». Servía como mecanismo, especialmente para Telnet, pero no era una tubería transparente.

El plan de transición de RFC 801 muestra esa estructura operacional. Telnet usaba una cuenta especial en un host de retransmisión antes de comenzar la segunda sesión. FTP movía el archivo hasta el relay y luego desde él. El correo tenía otro método. Había dos relaciones y un punto de custodia, no una equivalencia universal entre NCP y TCP/IP.

Confirmar la cola cercana no confirmaba al host lejano

El control de flujo revelaba una pérdida menos visible. En NCP, el mensaje Ready for Next Message lo enviaba el IMP de destino. Si la traducción estaba en medio, la señal podía provenir del IMP situado junto a la pasarela. Eso demostraba un acontecimiento cerca de la caja, no necesariamente la recepción, capacidad o consumo del extremo extranjero.

La pasarela podía retrasar la confirmación y almacenar datos. Pero entonces debía elegir qué acontecimiento del lado contrario liberaba el búfer. ¿La aceptación por su red local, la recepción por el transporte o el uso por la aplicación? Si el protocolo remoto no publicaba el hecho requerido, esperar más tiempo no convertía una señal local en evidencia de extremo a extremo.

El control de flujo es también una asignación de autoridad: quién debe frenar, qué recurso se protege y quién autoriza la reanudación. Dos suites podían colocar esos tres elementos en límites distintos. La caja no resolvía esa discrepancia al tener más memoria; la retenía como estado propio.

«Urgente» no identificaba al mismo destinatario de la orden

NCP ofrecía una orden de interrupción en un enlace de control. TCP tenía su mecanismo Urgent dentro de la conexión; Telnet definía Interrupt Process; la arquitectura ISO hablaba de datos expeditos. La semejanza verbal invitaba a dibujar una flecha entre ellos.

Pero RFC 793 atribuía a la indicación urgente una relación concreta con el usuario receptor y con las transiciones del modo urgente. Dar prioridad a un intérprete de protocolos no equivale necesariamente a ordenar al proceso final que interrumpa su tarea.

Ante una acción ausente, el traductor sólo disponía de decisiones con pérdida. Podía descartar la señal, imitar una acción diferente o terminar la aplicación y aplicar una política local. La tercera alternativa hacía visible que la pasarela estaba actuando como extremo; las otras podían esconder la misma autoridad bajo la palabra «traducción».

Padlipsky citó una pasarela de terminal de University College London entre Telnet de ARPANET y X.25/X.28/X.29. Según el alcance limitado del informe, los datos circulaban pero únicamente la opción de eco atravesaba el límite. No es una medición completa de aquel sistema. Es una advertencia metodológica: ver caracteres no demuestra que las opciones sobre su tratamiento también hayan sobrevivido.

La conversación hacía irremplazable a una máquina

Una pasarela capaz de mantener esas correspondencias guardaba dos identificadores de conexión, secuencias, ventanas o estados de flujo, asociaciones de direcciones, opciones y supuestos de aplicación. Un segundo equipo conectado en paralelo no conocía automáticamente ninguna sesión en curso.

RFC 875 llamó a la caja un punto de singularidad. El encaminamiento alternativo podía buscar otra ruta para un datagrama, pero no reconstruía la historia privada de una traducción. La alta disponibilidad exigía replicar estado, decidir quién era propietario, resolver conflictos y coordinar una toma de control. Una caja redundante sin ese protocolo sólo duplicaba el hardware.

También aparecía un problema combinatorio. Un traductor de A a B no resolvía A a C ni B a C. Al cambiar una suite, cada emparejamiento dependiente debía revisarse. La frontera centralizaba las cadencias de publicación y los casos ambiguos de sistemas que, por separado, podían evolucionar con independencia.

Un encaminador posterior seguía adaptando mucho

RFC 1009 definió después la pasarela Internet como encaminador de nivel IP. El equipo adaptaba tramas, MTU, direcciones de la red local e indicaciones locales de flujo o error; además elegía saltos, gestionaba búferes y participaba en el encaminamiento.

No era una función trivial. Su límite era otro: entre adaptaciones seguía existiendo un datagrama IP común. El encaminador no prometía recrear el reconocimiento de una aplicación extranjera ni transformar una orden para un intérprete en una interrupción del proceso final. «Delgado» describía el contrato común, no el tamaño del dispositivo.

Los documentos posteriores repitieron el examen, no la misma historia

RFC 2775 observó que traducir direcciones rompía la transparencia de extremo a extremo. Las aplicaciones que incluían direcciones en su carga requerían pasarelas de aplicación o proxies; una nueva aplicación dependiente de direcciones podía exigir nuevo conocimiento en el intermediario.

RFC 3234 catalogó los middleboxes, incluidos sus usos legítimos, y también sus nuevos fallos. El tráfico desviado podía alcanzar una instancia sin el estado anterior; un reinicio podía afectar sesiones; el diagnóstico debía atravesar capas. La caja que comprende una aplicación participa en su semántica.

RFC 4966 llevó NAT-PT a Historic por un conjunto concreto de problemas: direcciones embebidas, diferencias IPv4/IPv6, fragmentos, duración de mapeos, escalado de DNS-ALG y concentración de fallos o ataques. No demuestra que todo traductor sea inviable ni que RFC 875 anticipara cada sistema. Sí muestra por qué la traducción necesita especificar mucho más que el cambio de cabeceras.

La caja debía declarar qué significado era suyo

Para leer un diagrama de interconexión conviene sustituir cada flecha por cuatro preguntas: qué afirmación entra, qué afirmación sale, quién declara su equivalencia y qué evidencia puede comprobarla durante un fallo.

Con una capa mínima compartida, una pasarela preserva el objeto común y deja la variación local fuera de él. Sin esa capa, las opciones son explícitas: reducir el servicio a la intersección, cerrar y volver a originar, extender uno de los extremos o aceptar que una función no puede cruzar.

Que los bytes lleguen es un hecho importante, pero parcial. No prueba que la confirmación describa al extremo, que la urgencia mande al mismo actor, que las opciones conserven su alcance ni que otra instancia pueda continuar la sesión. RFC 875 obligó a retirar una ilusión del dibujo: una pasarela puede transportar un significado acordado; no puede descubrir dentro de los bytes una garantía que uno de los lados nunca formuló.

Fuentes