NAT: Una historia de amor y odio

17/10/2023

Por Henri Alves de Godoy – Computer Network Analyst | Profesor Ph.D. | IPv6 Evangelist

En 1996, Internet estaba empezando a desarrollarse en Brasil y la suscripción de un Proveedor de Acceso a Internet, como se le llamaba, era por horas de conexión y el excedente en minutos conectados se cobraba a parte en la factura de pago. La conexión se daba por medio de línea telefónica discada y cada usuario recibía un IP público en su casa. Por lo general un proveedor tenía, en principio, un promedio de 30 líneas telefónicas, era necesario solo un pequeño rango o bloque de direcciones IP públicas.

Era todo perfecto y normal, teníamos una identificación de usuario muy fácil y el registro del IP a través del tacacs o radius.  Algunos juegos saludables de acceso remoto (abrir y cerrar el CD-ROM del usuario), utilizando el NetBus y BackOrifice o incluso un Ping da Morte, eran posibles, ya que cada usuario conectado a Internet vía modem discado, recibía un IP accesible globalmente. Controles de acceso, firewalls y los conceptos de seguridad de cómo filtrar y bloquear amenazas todavía estaban en desarrollo y estudios.

¿Pero cómo se lograba encontrar el IP del usuario conectado? Mira, había algunas maneras, en donde la más simple era a través del mIRC (programa cliente del IRC – Internet Relay Chat) y llamar a tu amigo para un chat privado. Después, bastaba con ejecutar un comando nestat y el IP remoto del usuario se descubría.

Por otro lado, a nivel mundial, el IETF (Internet Engineering Task Force) discutía en 1991, que con el crecimiento de Internet el agotamiento de las direcciones IPv4 era inminente, con fecha prevista para fines del año 1994. Como solución rápida, se adoptó el CIDR (Classless Inter-Domain Routing) para poder quebrar en subredes ahora las atribuciones de clases de IP (A,B,C) con el objetivo de distribuir en bloques menores y atender de forma optimizada los que solicitaban IP para soportar el crecimiento de Internet. Con eso fue posible darle un descanso al IPv4, pero no fue suficiente.

Durante la administración del Proveedor de Internet en donde trabajé, había un bloque/24 de IPv4 cedido a Embratel. La mitad se destinaba a los usuarios comerciales discados y la otra mitad para uso administrativo y servidores de la facultad que abrigaban al proveedor. Llegaron entonces los laboratorios de informática, aumento de líneas por discado, el crecimiento de servidores y del cuerpo administrativo de funcionarios de la Facultad. Pronto no había más direcciones IPv4 disponibles para soportar ese crecimiento.

Concomitante a eso, con el crecimiento de la Internet más allá de las expectativas, una RFC 1918 se publicó en 1996 con “Buenas Prácticas de Internet”, definiendo el concepto de IP privado. La Internet Assigned Numbers Authority (IANA) reservó tres bloques de espacio de direcciones IP para las redes privadas, descrito en la Figura 1.

La idea inicial era preservar o utilizar las direcciones IP públicas solo en host que necesitaban un acceso externo o global, en el intento de prolongar la vida útil de la dirección IPv4. Hosts que accedían a otros desde una misma red interna, servicios locales, impresoras, compartido de archivos, ahora podrían tener números IP privados.

Hasta ese entonces la definición de red privada y pública (interna y externa) estaba bien descrita y los dispositivos pertenecientes a cada red también. Fue entonces cuando el desgano nos dominó a nosotros mismos, profesionales de redes y administradores, ya que, alterar una configuración de IP, DNS, Gateway, cuando un host privado precisaba en ese momento una conexión externa (IP público), era una tarea muy engorrosa y nada práctica.

Surgió entonces la maravillosa idea de facilitar la vida de todos, creando una técnica para traducción y ruteo de las direcciones IP pertenecientes a una red interna (privada), para lograr acceder a una red externa (pública) de forma transparente y viceversa, sin modificar las configuraciones de los hosts. Fue así como surgió la terminología NAT (Network Address Translation), siendo descripta en la RFC 2663 en 1999. El foco del artículo no es discutir en profundidad los tipos de NAT existentes, pero los más comunes que utilizamos son: NAT de salida (Masquerade), NAT de puertas (NAPT), NAT bidireccional. Hay varios sabores para todos los gustos. Un ejemplo de un NAT básico se puede ver en la Figura 2.

Ahí estaba la solución para mi problema en esa época y la de muchos proveedores de acceso a Internet, que con la llegada y el crecimiento exponencial de los usuarios de banda ancha ADSL y luego las apariciones de proveedores vía Radio, sería imposible asignar, como antes, IP públicos para todos los clientes finales.

Muchos destacan las bondades del uso del NAT. Algunas muy polémicas que ya fueron escenario de acaloradas discusiones que involucran la seguridad y el aumento de la red (oscuridad) por no estar en contacto directo con el mundo externo. Deje sus comentarios.

La verdad es que con NAT se hace mucho más fácil y fue del agrado de mucha gente, con una receta mágica perfecta, utilizando los proxies Squid y los redireccionamientos y mapeos de IP/Porta con IPchains e IPtables en Linux. Ya pasamos más de 20 años utilizando NAT y esa facilidad conquistó hoy nuestro corazón de manera tan automática que no podríamos acostumbrarnos a vivir sin ella. Nos viciamos tanto con esa práctica que muchos ahora tienen dificultad para deshacerse de ella.

¿Existirá un tratamiento? ¿Necesitamos un grupo de NAT Anónimos de Brasil?

Sí, existe. El tratamiento y cura se llama IPv6. Estamos teniendo la primera oportunidad real de volver a la época de la primera y única migración de un protocolo de nivel mundial ocurrida en 1983 (hace 40 años). Con la cantidad de direcciones IPv6 no hay más necesidad de economía de direcciones y volveremos a la época de 1996, donde cada usuario recibía en casa una dirección pública, ahora llamada global.

Pero, a ver, la etapa de transición para el IPv6 está usando NAT, muchos me lo preguntan, entonces estamos en la misma. Vieron que no hay cómo librarse de ese vicio. La traducción existente en los mecanismos de transición existentes, por ejemplo: NAT64, 464XLAT, SIIT-DC son necesarias, así como fueron necesarias en 1996. Sin embargo, ahora sabemos que hay un salida, una luz al final del túnel y que podemos aprovechar todo lo que aprendemos (o no) en esos más de 20 años de NAT, para entender que ahora es posible desarrollar la conectividad fin a fin a los usuarios finales en Internet.

Por lo tanto, no debemos acostumbrarnos a un largo período de dependencia de esas herramientas de transición hacia el IPv6. Hay que empezar a pensar en un mundo solo con IPv6 en los servicios, aplicaciones, juegos on-line, streaming, lo antes posible. Cuanto más rápido tomemos la medicina llamada IPv6, nos tratemos y nos prevengamos de ese vicio llamado NAT, más rápido recuperaremos nuestra salud y podremos ser testigos de la liberación y cura de ese mal.

Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.