Durante años, la frase funcionó como argumento definitivo: “NAT es gratis”. Si IPv4 seguía funcionando, si las redes podían esconder cientos o miles de dispositivos detrás de una sola dirección pública y si migrar a IPv6 obligaba a tocar direccionamiento, firewalls, monitorización, aplicaciones y procedimientos, la decisión parecía sencilla. No migrar salía más barato.
Ese cálculo fue razonable durante mucho tiempo. El problema es que la premisa ha cambiado. NAT no se ha vuelto caro de repente porque un estándar lo diga, sino porque la escasez de IPv4 ha convertido en coste todo lo que antes parecía invisible: direcciones públicas, equipos CGNAT, logging, soporte, operaciones, cumplimiento legal y complejidad de red.
La dirección IPv4 ya no es un recurso administrativo que se pide sin más al registro regional. Es un activo con precio. RIPE NCC agotó su pool disponible en noviembre de 2019 para Europa, Oriente Medio y parte de Asia Central, y ARIN había agotado el suyo en Norteamérica en septiembre de 2015. Desde entonces, quien necesita más IPv4 tiene que reutilizar, transferir, alquilar, comprar o esconder más usuarios detrás de NAT.
La IP pública ya tiene una línea de factura
AWS hizo visible lo que muchos operadores ya sabían. Desde el 1 de febrero de 2024 cobra 0,005 dólares por hora por cada dirección IPv4 pública, esté asociada a un servicio o permanezca ociosa. La cifra parece pequeña, pero equivale a 43,80 dólares al año por dirección. En entornos con decenas, cientos o miles de IPs públicas, deja de ser un redondeo.
Ese cargo no paga cómputo, almacenamiento ni tráfico. Paga la dirección. Es la escasez convertida en unidad de consumo cloud. AWS no inventó el problema, pero lo tradujo a una métrica que cualquier responsable de infraestructura puede entender: cada IPv4 pública tiene coste recurrente.
El mercado secundario cuenta la misma historia desde otro ángulo. Informes de mercado sitúan el precio de compra de IPv4 en 2026 entre 18 y 45 dólares por IP, según tamaño de bloque y región, y el alquiler entre 0,30 y 0,50 dólares por IP al mes. Otros análisis de transacciones del primer semestre de 2025 apuntan a precios medios cercanos a 31 dólares por dirección.
| Coste visible de IPv4 | Ejemplo |
|---|---|
| IPv4 pública en AWS | 0,005 $/hora |
| Coste anual por IPv4 en AWS | 43,80 $/año |
| Compra de IPv4 en mercado secundario | 18-45 $/IP en 2026, según bloque |
| Alquiler de IPv4 | 0,30-0,50 $/IP/mes |
| Precio medio en operaciones H1 2025 | 31,15 $/IP, según IPv4 Center |
Lo que antes era parte del paisaje ahora aparece en la factura. Y cuando una dirección empieza a cobrarse como un recurso escaso, el argumento de que NAT sale gratis pierde la parte más simple de su defensa.
CGNAT: la caja que existe porque no hay direcciones
La segunda factura es menos visible. Cuando un operador no puede entregar una IPv4 pública directa a cada cliente, suele recurrir a Carrier-Grade NAT, o CGNAT. En la práctica, muchos abonados comparten una o varias direcciones públicas y el operador traduce sus conexiones mediante puertos.
Eso requiere equipos específicos, capacidad de procesamiento, memoria para tablas de estado, redundancia, licencias, soporte, energía, refrigeración, espacio en rack, monitorización y personal que sepa dimensionar y depurar la plataforma. El CGNAT no es una función abstracta. Es una pieza crítica en el camino del tráfico.
El IETF documentó requisitos comunes para CGNAT precisamente porque estas plataformas tienen que comportarse con cuidado en gestión de puertos, sesiones, temporizadores y reutilización de mappings. Cuando un equipo está traduciendo millones de sesiones, detalles como cuándo se puede reutilizar un puerto o cómo se conserva el estado no son menores: afectan a aplicaciones, trazabilidad y estabilidad.
El mercado ya refleja esa capa de gasto. DataIntelo valoró el mercado global de Carrier-Grade NAT en 3.800 millones de dólares en 2025 y proyectó 9.100 millones para 2034. Es una estimación de mercado, no una contabilidad universal de todos los operadores, pero ayuda a poner dimensión económica a algo que durante años se describió como “una solución temporal”.
| Coste oculto del CGNAT | Por qué existe |
|---|---|
| Appliances o capacidad virtualizada | Traducir tráfico de muchos abonados |
| Redundancia | Evitar que una caída afecte a miles de usuarios |
| Licencias y soporte | Mantener plataformas de alto rendimiento |
| Energía y rack | Operar hardware adicional |
| Monitorización | Detectar agotamiento de puertos y degradaciones |
| Operación NOC | Resolver incidencias que no existirían con IP directa |
La idea importante es incómoda: ese equipo solo existe porque no hay suficientes IPv4 públicas o porque el operador decide conservarlas. En una red con asignación directa, parte de esa complejidad desaparece.
El logging es otra factura, y puede ser enorme
CGNAT rompe una relación sencilla: una IP pública ya no identifica a un abonado. Si cien, mil o diez mil usuarios comparten una dirección, cualquier investigación de abuso, fraude o requerimiento legal necesita algo más que una IP y una hora. Necesita IP pública, puerto público, IP privada, puerto privado y timestamp.
El IETF ya señalaba en trabajos sobre CGN que los operadores pueden necesitar identificar a un abonado a partir de IP externa, puerto y marca temporal para responder a abusos o requerimientos legales. RFC 7422 lo expresa con claridad: muchas soluciones CGN requieren logging activo de traducciones dinámicas, y el objetivo de algunas técnicas deterministas es reducir precisamente ese volumen de logs.
Esto no se parece a guardar una concesión DHCP. Es registrar traducciones de sesiones a gran escala. En redes grandes, la retención y consulta de esos datos implica colectores, exportación IPFIX o NetFlow, almacenamiento, compresión, políticas de acceso, auditoría y herramientas de correlación. También implica responsabilidad: esos logs son sensibles, deben protegerse y, al mismo tiempo, tienen que estar disponibles cuando se necesitan.
NAT, por tanto, no solo consume hardware. Consume compliance. Y ese coste rara vez se imputa mentalmente a la decisión de no desplegar IPv6 de forma completa.
IPv6 no es gratis, pero sí cambia la ecuación
Migrar a IPv6 también tiene coste. Nadie serio debería negarlo. Hay que revisar direccionamiento, firewalls, balanceadores, monitorización, DNS, VPNs, reglas de seguridad, aplicaciones heredadas, herramientas de observabilidad y formación. En empresas con muchos años de deuda técnica, dual-stack puede convertirse en un proyecto largo.
Pero el punto ya no es comparar “IPv6 caro” contra “IPv4 gratis”. Esa comparación murió. La comparación real es entre el coste de desplegar y operar IPv6 frente al coste acumulado de seguir estirando IPv4 con NAT, CGNAT, direcciones compradas o alquiladas, troubleshooting extra y logging masivo.
La adopción global también ha dejado de ser marginal. Google mide de forma continua el porcentaje de usuarios que acceden a sus servicios por IPv6 y en junio de 2026 situaba esa cifra cerca del 49 %. APNIC destacó en abril de 2026 el hito del 50 % en la medición de Google, una señal de que IPv6 ya no es una tecnología futura, sino parte normal del tráfico de internet.
Esto no significa que IPv4 vaya a desaparecer mañana. Seguirá durante años. La transición real es dual-stack, con islas, traducción, compatibilidad y muchas excepciones. Pero cada año que pasa, la pregunta cambia: ya no es si IPv6 está preparado, sino cuántas capas artificiales se mantienen para retrasarlo.
Lo que deberían mirar cloud, ISPs y empresas
En cloud, la revisión empieza por inventariar IPv4 públicas. Elastic IPs olvidadas, balanceadores con direcciones públicas innecesarias, NAT Gateways mal dimensionados, servicios expuestos sin necesidad o arquitecturas que podrían funcionar con IPv6 para tráfico saliente o interno. La factura de AWS hizo que muchas organizaciones descubrieran que tenían más IPv4 públicas de las que creían.
En operadores, la pregunta es más estructural. ¿Cuánto CAPEX se dedica a plataformas CGNAT? ¿Cuánto coste operativo arrastra el logging? ¿Cuántas incidencias de cliente vienen de agotamiento de puertos, juegos online, VPNs, videollamadas, teletrabajo o servicios que no toleran bien estar detrás de CGNAT? ¿Cuánto se está invirtiendo en sostener una escasez que IPv6 resuelve en origen?
En empresas, el problema suele estar en la mezcla. Muchas ya tienen IPv6 en el acceso de usuarios, móviles o proveedores, pero no lo observan bien. Sus firewalls, SIEM, reglas, CMDB y dashboards siguen pensando en IPv4. Esa ceguera puede ser tan peligrosa como la falta de adopción: parte del tráfico ya va por IPv6 aunque la operación siga mirando solo IPv4.
La frase “NAT es gratis” sobrevivió porque los costes estaban repartidos. Un poco en cloud. Un poco en red. Otro poco en cumplimiento. Otro en soporte. Otro en tiempo perdido por operaciones. Al unirlos, la conclusión cambia.
NAT fue una solución brillante para ganar tiempo. Lo que no puede ser es una excusa eterna para no hacer la cuenta completa. IPv6 no elimina todos los problemas de red, pero sí ataca el origen de uno de los más caros: la escasez artificial de direcciones públicas.
La factura ya existe. Solo que llega partida en demasiadas líneas para que alguien la llame por su nombre.
Preguntas frecuentes
¿NAT es realmente gratis?
No. NAT puede no tener una licencia directa en todos los casos, pero genera costes en direcciones IPv4, appliances CGNAT, operación, soporte, logging, cumplimiento y resolución de incidencias.
¿Por qué AWS cobra por IPv4 pública?
AWS aplica desde febrero de 2024 un cargo de 0,005 dólares por hora por IPv4 pública, esté en uso u ociosa, para reflejar el coste y la escasez de este recurso.
¿Qué es CGNAT?
Carrier-Grade NAT es una técnica usada por operadores para que muchos clientes compartan direcciones IPv4 públicas mediante traducción de puertos y sesiones.
¿Por qué CGNAT obliga a guardar más logs?
Porque una IP pública compartida ya no identifica a un abonado. Para reconstruir una conexión hay que correlacionar IP pública, puerto, IP privada, puerto y tiempo.
¿IPv6 elimina la necesidad de NAT?
IPv6 permite asignar direcciones únicas de forma amplia y reduce la necesidad estructural de NAT. Puede seguir habiendo firewalls, segmentación y políticas de seguridad, pero no la misma escasez de direcciones.
Referencias: Linkedin y Agotamiento de IPv4
