Resumen

  • La NAT podía ahorrar direcciones IPv4 globalmente únicas en la frontera de una red; las aplicaciones que dependían de esos valores necesitaban algo más que reescribir la cabecera IP.
  • La advertencia histórica de la RFC 2993 fue sobre dónde acababa ese trabajo: pasarelas de aplicación, actualizaciones coordinadas de los extremos, gestión local de nombres y soporte, no solo un aparato en el camino del router.

Un traductor puede ejecutar correctamente su regla y dejar una aplicación sin capacidad para conectarse. La tabla de traducción no tiene por qué estar mal. El problema puede aparecer cuando una dirección identifica un equipo dentro de una red privada, representa otro valor en el exterior y vuelve a aparecer dentro de los mensajes de la propia aplicación.

La tensión ya estaba presente en la propuesta de 1994. La RFC 1631 presentó Network Address Translation como una respuesta incremental a la presión sobre IPv4: las redes finales podían reutilizar direcciones internas y un dispositivo fronterizo traducía el tráfico que salía al espacio global. El documento también reconocía el intercambio: la dirección IP perdía parte de su significado de extremo a extremo y la red adquiría estado adicional. Si una organización tenía varias salidas, los traductores debían mantener una visión coherente de sus correspondencias. Era un puente práctico, no una arquitectura sin costes.

En noviembre de 2000, Tony Hain revisó la NAT tras seis años de interés y despliegue crecientes en la RFC 2993. La cuestión ya no era solo si un router podía sustituir una dirección por otra. Era si el servicio seguiría funcionando cuando esa dirección aparecía en un lugar que el traductor no inspeccionaba.

La respuesta dependía de la aplicación. Un intercambio sencillo entre dos extremos a través de una NAT podía ser manejable. Pero algunos protocolos llevaban direcciones IP en su carga útil; otros dependían de que la cabecera se mantuviera coherente para las sumas de comprobación, la autenticación o la seguridad. Un traductor limitado a cabeceras no podía corregir todos esos supuestos. Las pasarelas de nivel de aplicación (ALG) y los proxies podían ayudar, pero cada uno debía entender el protocolo que reparaba. La RFC 2775 había señalado algo parecido ese mismo año: una ALG o un proxy debía actualizarse cuando aparecía una aplicación nueva que dependía de direcciones.

Así, la “transparencia” se convirtió en una promesa condicionada. Si la aplicación no exponía ni utilizaba la dirección traducida, la función fronteriza podía pasar inadvertida. Si lo hacía, alguien tenía que coordinar la solución en todos los lugares donde se ejecutaba esa aplicación. La RFC 2993 contrapone el caso relativamente sencillo de dos extremos con rutas NAT redundantes y aplicaciones multipunto, como compartir documentos. Dice que la complejidad de coordinar esas soluciones crece geométricamente con el número de extremos.

No ofrece una ecuación ni una curva de costes medida: describe un problema arquitectónico de escala, no un resultado experimental.

La redundancia añadía otra dependencia de estado. Dos traductores en caminos alternativos necesitaban compartir una interpretación coherente de las correspondencias de un equipo. Si el estado de una conexión quedaba en un camino y el tráfico cambiaba al otro, la segunda ruta podía crear una correspondencia distinta. Volver a la ruta original no garantizaba recuperar la conversación. La dirección del paquete no era todo el estado: también importaban la correspondencia del traductor y su ubicación en el camino.

El coste podía pasar de una organización a otra. La RFC 2993 observó que una NAT administrada por el proveedor de Internet podía simplificar una parte de su soporte y aumentar, a la vez, la administración local de direcciones y nombres. Es un traslado de carga descrito por el documento, no una medición universal de que el coste total subiera. Tras una fusión, por ejemplo, un administrador local podía tener que resolver direcciones privadas duplicadas, organizar respuestas DNS internas y externas o coordinar una corrección de la aplicación antes invisible para el proveedor.

La seguridad acentuaba la diferencia entre traducción y política. La RFC advierte que la NAT —en especial la traducción de puertos— puede dar la impresión de una barrera de seguridad sin la intención explícita de control de acceso propia de un cortafuegos. También detalla problemas de compatibilidad con IPsec, ciertas operaciones DNS y la autenticación SNMPv3. Son mecanismos dependientes del protocolo y de la configuración, no una prueba de que cualquier NAT inutilice cualquier protocolo de seguridad. El traductor cambia evidencia dependiente de direcciones; por sí solo no decide qué tráfico se permite.

La documentación posterior hizo más visible el trabajo, no demuestra que desapareciera. La RFC 3022 sustituyó a la RFC 1631 con una descripción de la NAT tradicional en 2001. La RFC 3235 publicó en 2002 pautas para diseñar aplicaciones compatibles con NAT. Esos textos no prueban que la RFC 2993 causara un despliegue concreto ni que todos los programas siguieran las pautas. Sí muestran cómo una técnica de frontera generó literatura de diseño para aplicaciones.

La aportación histórica de la RFC 2993 no es dictaminar que toda NAT fracasa. Separa el ahorro de direcciones en la frontera del trabajo de compatibilidad que hace falta por encima. El traductor podía instalarse en una sola puerta de enlace; reparar el servicio podía exigir cambios en muchos extremos, mantener estado coherente en varios caminos y dar control local a los nombres. La red no hizo desaparecer ese trabajo: cambió quién tenía que detectarlo y coordinarlo.

Fuentes