Publicado:
Última actualización:
Carrier-Grade NAT, o CGNAT, es una función de red del proveedor de servicios que permite que varios abonados compartan la misma dirección IPv4 pública. En lugar de asignar una dirección pública a cada cliente, un ISP traduce el tráfico de numerosas conexiones de abonados a través de un conjunto más pequeño de direcciones IPv4 públicas.
CGNAT resulta útil cuando el objetivo es conservar la capacidad IPv4 pública. La contrapartida es que los abonados dejan de tener una relación uno a uno con la dirección pública visible en Internet. Esto puede afectar a la conectividad entrante, la disponibilidad de puertos, la atribución de abonados, la resolución de problemas y los servicios que dependen de una dirección IPv4 pública diferenciada.
La cuestión práctica no es si CGNAT es bueno o malo.
¿Cuándo es suficiente una IPv4 pública compartida y cuándo necesita un cliente capacidad IPv4 pública propia?
CGNAT realiza la traducción de direcciones de red dentro de la red del proveedor de servicios.
Una red doméstica típica ya utiliza NAT:
Portátil / teléfono / TV
↓
Direcciones IPv4 privadas
192.168.x.x
↓
NAT del router doméstico
↓
Dirección IPv4 pública
↓
Internet
El router del cliente traduce el tráfico de varios dispositivos privados a la dirección IPv4 pública asignada a la conexión.
Con CGNAT, el proveedor de servicios añade otra capa de traducción:
Dispositivos del cliente
↓
Router doméstico
↓
Dirección del lado del cliente
↓
CGNAT del ISP
↓
Pool IPv4 público compartido
↓
Internet
Por lo tanto, muchos despliegues incluyen dos dominios de traducción: NAT dentro de la red del cliente y CGNAT dentro de la red del proveedor.
El IETF define un Carrier-Grade NAT como una función basada en NAT utilizada para compartir la misma dirección IPv4 entre varios abonados, donde el CGN es gestionado por el proveedor de servicios y no por los abonados. Esta definición y los requisitos operativos habituales están documentados en RFC 6888: Common Requirements for Carrier-Grade NATs.
CGNAT no distingue a los abonados utilizando únicamente la dirección IP pública.
Los puertos de la capa de transporte también forman parte de la traducción.
Un ejemplo simplificado podría verse así:
Abonado A
100.64.10.20:50001
↓
203.0.113.20:22001
Abonado B
100.64.20.30:51002
↓
203.0.113.20:22002
Abonado C
100.64.30.40:52003
↓
203.0.113.20:22003
Desde la perspectiva de un servicio externo, los tres abonados pueden parecer conectarse desde:
203.0.113.20
La plataforma CGNAT mantiene el estado de las traducciones para que el tráfico de retorno pueda asignarse al abonado y a la conexión correctos.
Este uso compartido de direcciones y puertos es lo que permite que un pool IPv4 público relativamente pequeño pueda atender a un número mucho mayor de usuarios.
Los ISP utilizan CGNAT principalmente para reducir la cantidad de capacidad IPv4 pública necesaria por abonado.
Pensemos en un proveedor de acceso que atiende a cientos de miles de clientes residenciales. Asignar a cada conexión su propia dirección IPv4 pública consume un pool de direcciones proporcionalmente grande.
CGNAT cambia el modelo de asignación de:
1 abonado = 1 IPv4 pública
a algo más parecido a:
muchos abonados = capacidad IPv4 pública compartida
Esto hace que CGNAT sea útil para redes de banda ancha, móviles, inalámbricas y otras grandes redes de acceso donde la mayor parte del tráfico de los clientes es saliente.
LARUS aborda CGNAT junto con otros enfoques de gestión de direcciones en su guía sobre cómo los ISP gestionan la escasez de IPv4.
La distinción importante es sencilla:
CGNAT no crea nuevas direcciones IPv4. Permite compartir de forma más intensiva la capacidad IPv4 pública existente.
El prefijo IPv4 100.64.0.0/10 es un espacio de direcciones compartidas reservado para redes de proveedores de servicios, incluidos los despliegues CGN.
El rango se extiende desde:
100.64.0.0 hasta 100.127.255.255
El IETF asignó este espacio en RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space. El documento distingue el espacio de direcciones compartidas del espacio de direcciones privadas RFC 1918 porque está destinado específicamente al uso dentro de redes de proveedores de servicios.
Por tanto, es diferente de los rangos privados habituales, como:
10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
100.64.0.0/10 tampoco es un espacio IPv4 público ordinario enrutable globalmente.
Si el router de un cliente recibe una dirección WAN entre 100.64.0.0 y 100.127.255.255, es una señal clara de que puede estar presente CGNAT.
Sin embargo, no es un método de detección universal. Las arquitecturas de los proveedores varían y no todos los despliegues de direcciones compartidas tienen que verse de la misma manera desde el lado del cliente.
La principal diferencia entre el NAT tradicional del cliente y CGNAT es dónde se realiza la traducción y quién comparte la dirección pública.
El NAT tradicional generalmente permite que los dispositivos dentro de una misma red de cliente compartan una dirección pública controlada en el router del cliente.
CGNAT añade una traducción a nivel del proveedor de servicios, permitiendo que varias redes de abonados independientes compartan capacidad IPv4 pública.
| Característica | NAT del cliente | CGNAT |
|---|---|---|
| Operado por | Cliente | ISP o proveedor de servicios |
| Alcance del uso compartido | Dispositivos dentro de una red | Varios abonados |
| Control de la traducción | El cliente suele controlar el router | El proveedor controla el CGN |
| Relación con la IPv4 pública | Normalmente asociada a una conexión de cliente | Compartida entre clientes |
| Redirección de puertos | A menudo configurable | Normalmente más limitada |
| Atribución | La IP pública suele limitar la actividad a una conexión de cliente | La IP pública por sí sola puede representar a muchos abonados |
| Registro | Principalmente local | El proveedor puede necesitar una correlación detallada de abonados y sesiones |
Para conocer el modelo de traducción subyacente, consulte la guía de LARUS sobre Network Address Translation y cómo funciona NAT .
Por tanto, CGNAT no es simplemente otro nombre para el NAT doméstico. Traslada el uso compartido de direcciones a gran escala a la red del proveedor.
Una dirección IPv4 pública compartida puede representar a muchos abonados al mismo tiempo.
Esto significa que una dirección IP pública por sí sola puede no identificar qué abonado generó una conexión concreta.
Supongamos que un informe de abuso contiene únicamente:
IP pública: 203.0.113.20 Hora: 14:35 UTC
Si cientos de abonados compartían esa dirección a las 14:35, la dirección por sí sola puede ser insuficiente para una atribución precisa.
Información más útil podría incluir:
IP pública: 203.0.113.20 Puerto origen: 22002 Marca de tiempo: 14:35:27 UTC Protocolo: TCP
El proveedor de servicios puede entonces correlacionar esa información con sus asignaciones de abonados o registros de traducción CGN.
RFC 6888 aborda el registro de CGN y señala las implicaciones operativas de registrar suficiente información para identificar al abonado asociado con una sesión traducida.
Esto crea una importante compensación de ingeniería:
CGNAT puede reducir el consumo de IPv4 pública al tiempo que aumenta la importancia de un mapeo preciso de sesiones, marcas de tiempo, infraestructura de registro y procesos de respuesta ante abusos.
CGNAT funciona bien para muchas aplicaciones normales de Internet basadas en conexiones salientes.
Las limitaciones se hacen más visibles cuando una carga de trabajo depende de conectividad entrante no solicitada, un comportamiento predecible de los puertos o una dirección de origen pública diferenciada.
El RFC 6269: Issues with IP Address Sharing del IETF describe varias consecuencias del uso compartido de direcciones a gran escala, incluidos los efectos sobre las conexiones entrantes, las aplicaciones que presuponen direcciones de origen únicas, la supervisión, la seguridad, la asignación de puertos y los controles basados en IP.
Un cliente detrás de CGNAT generalmente no controla la traducción del lado público del proveedor.
Esto puede complicar:
Aplicaciones autoalojadas
Servicios de acceso remoto
Servidores operados por el cliente
Aplicaciones peer-to-peer
Algunas configuraciones VPN
Cámaras de seguridad
Determinados escenarios de videojuegos
Las aplicaciones y los proveedores pueden admitir mecanismos de traversal o diseños alternativos, pero una conexión CGNAT no debe considerarse automáticamente equivalente a disponer de una IPv4 pública directamente utilizable.
Una dirección IPv4 pública tiene un espacio finito de puertos de transporte.
Cuando muchos abonados comparten la misma dirección, la plataforma CGN debe distribuir los puertos y mantener el estado de traducción entre ellos.
Por tanto, los operadores deben considerar algo más que:
¿Cuántas direcciones IPv4 públicas están disponibles?
También deben considerar:
¿Cuántas traducciones simultáneas y puertos utilizables pueden admitirse con la proporción de uso compartido prevista?
Un uso compartido agresivo puede ahorrar capacidad de direcciones mientras genera presión en otras partes de la arquitectura del servicio.
Los servicios externos suelen utilizar la IP de origen como una señal al aplicar:
Controles contra abusos
Detección de fraude
Filtrado de spam
Límites de frecuencia
Políticas de seguridad
Puntuación de reputación
Con CGNAT, abonados no relacionados pueden compartir esa misma señal.
Si una dirección IPv4 pública compartida es bloqueada o desarrolla una mala reputación, los clientes que no tuvieron nada que ver con el comportamiento que provocó el problema también pueden experimentar dificultades.
RFC 6269 analiza este tipo de impacto colateral como una de las consecuencias del uso compartido de direcciones IP a gran escala.
La comparación más útil no es CGNAT frente a ausencia de NAT.
La cuestión es si el servicio requiere acceso IPv4 saliente compartido o capacidades IPv4 públicas directas.
| Requisito | CGNAT | IPv4 pública |
|---|---|---|
| Navegación web general | Adecuado | Adecuado |
| Streaming | Normalmente adecuado | Adecuado |
| Conservar capacidad IPv4 | Gran ventaja | Sin ventaja de uso compartido |
| Dirección de origen pública diferenciada | No | Sí |
| Acceso entrante controlado por el cliente | Restringido | Más adecuado |
| Redirección de puertos | Normalmente difícil | Más controlable |
| Alojamiento de servicios públicos | A menudo limitado | Más adecuado |
| Lista blanca de IP | Una dirección compartida puede ser problemática | Una dirección dedicada es más clara |
| Atribución de abonados | Requiere correlación de puerto y hora | Más sencilla a nivel de dirección |
| Aislamiento de reputación | Compartido | Mayor aislamiento |
| Uso de IPv4 pública por abonado | Bajo | Más alto |
Las dos arquitecturas resuelven problemas diferentes.
CGNAT optimiza la utilización de direcciones. La IPv4 pública proporciona a una red o a un cliente una relación más directa con la dirección visible en Internet.
Las dos arquitecturas resuelven problemas diferentes.
CGNAT optimiza la utilización de direcciones. La IPv4 pública proporciona a una red o a un cliente una relación más directa con la dirección visible en Internet.
CGNAT es adecuado para servicios en los que los abonados principalmente inician conexiones salientes y no necesitan controlar una dirección IPv4 expuesta públicamente.
Algunos ejemplos habituales son:
Banda ancha residencial
Acceso móvil a Internet
Grandes redes de consumidores
Wi-Fi público
Conectividad IoT orientada al tráfico saliente
Servicios de Internet básicos
Para estos clientes, dedicar una dirección IPv4 pública a cada abonado puede aportar poco valor operativo adicional en comparación con la cantidad de capacidad de direcciones consumida.
CGNAT permite al operador utilizar IPv4 pública de forma más selectiva.
La IPv4 pública adquiere mayor importancia cuando una carga de trabajo depende de capacidades de red que el uso compartido de direcciones a gran escala restringe.
Algunos ejemplos son:
Alojamiento de aplicaciones públicas
Puertas de enlace VPN empresariales
Listas blancas de firewall empresariales
Infraestructura de acceso remoto
Servicios entrantes controlados por el cliente
Dispositivos de red que requieren direccionamiento público predecible
Servicios sensibles a la reputación de una IP compartida
Conectividad empresarial que requiere direccionamiento público de salida estable
Un proveedor de servicios no tiene que elegir un único modelo para todos sus clientes.
Un diseño segmentado puede verse así:
Residencial / banda ancha básica
↓
CGNAT
Conectividad empresarial
↓
Opción de IPv4 pública
Alojamiento / infraestructura
↓
Capacidad IPv4 pública enrutada
CGNAT puede conservar capacidad de direcciones cuando el uso compartido se adapta a la carga de trabajo, mientras que una IPv4 pública dedicada o enrutada sigue estando disponible para los servicios que la necesitan.
Una arquitectura CGNAT sigue necesitando IPv4 pública en el lado orientado a Internet.
Los operadores también pueden necesitar capacidad de direcciones separada para abonados empresariales, clientes de alojamiento, servicios públicos, productos de infraestructura o clientes que requieran excepciones al modelo de direcciones compartidas.
A medida que la red crece, la planificación de capacidad se convierte, por tanto, en una combinación de:
Tráfico adecuado para IPv4 compartida + Tráfico que requiere IPv4 pública + Capacidad reservada para crecimiento
Por eso el uso compartido de direcciones es solo una parte del problema más amplio de escasez de IPv4 y planificación de capacidad.
Si aumentan los productos de IP empresariales, la demanda de alojamiento, las excepciones de direcciones públicas, el crecimiento de abonados o la presión sobre los puertos CGN, la cuestión pasa a ser más amplia que simplemente cómo configurar NAT. Se convierte en una decisión sobre capacidad IPv4 pública.
Consulte la disponibilidad de IPv4 de LARUS y Continuity Assurance para evaluar capacidad IPv4 adicional de producción junto con una arquitectura CGNAT existente.
LARUS ofrece actualmente alquiler de IPv4 de primera parte desde su propio pool de direcciones y proporciona controles de continuidad que cubren áreas como la validez del enrutamiento, rDNS, preparación para RPKI/ROA, reputación, gestión de abusos, geolocalización, respuesta de soporte y renovación.
CGNAT puede reducir el consumo de IPv4 pública, pero añade trabajo operativo en otras áreas.
Dependiendo de la red y de los requisitos, los operadores pueden tener que gestionar:
Infraestructura de traducción
Capacidad de sesiones
Asignación de puertos
Mapeo de abonados
Sincronización horaria
Generación y almacenamiento de registros
Investigaciones de abuso
Reputación de direcciones compartidas
Excepciones para clientes
Niveles de servicio con IP pública dedicada
BTW.Media analiza el aspecto del registro de este problema en su análisis sobre los requisitos de registro de CGNAT y los costes de la escasez de IPv4, incluida la infraestructura necesaria para los registros de traducción, la precisión temporal, el almacenamiento y la atribución de abonados.
Para los operadores, esto conduce a una elección de diseño específica para cada carga de trabajo: utilizar direccionamiento compartido donde satisfaga los requisitos del cliente y conservar capacidad IPv4 pública cuando sean importantes la accesibilidad directa, el direccionamiento de origen diferenciado, el aislamiento de reputación o un mayor control.
No. 100.64.0.0/10 es un espacio de direcciones compartidas reservado para el uso de proveedores de servicios. RFC 6598 define el rango para escenarios que incluyen Carrier-Grade NAT y lo distingue del espacio IPv4 público ordinario.
Compare la dirección IPv4 WAN que muestra su router con la dirección IPv4 pública que ve un servicio de Internet. Si son diferentes —y especialmente si el router tiene una dirección dentro de 100.64.0.0/10— puede estar presente CGNAT. Las arquitecturas de los proveedores varían, por lo que su ISP puede ofrecer la respuesta definitiva.
CGNAT normalmente dificulta la redirección de puertos entrantes controlada por el cliente porque este no controla la capa de traducción externa del proveedor. Algunos proveedores o aplicaciones admiten mecanismos alternativos, por lo que el comportamiento exacto depende del despliegue. RFC 6269 analiza los problemas que el uso compartido de direcciones crea para los puertos y las conexiones entrantes.
No necesariamente. Muchas aplicaciones funcionan con normalidad, mientras que aquellas que dependen de sesiones entrantes, conectividad directa entre pares, un comportamiento NAT específico o mapeos de puertos predecibles pueden experimentar limitaciones. El resultado depende de la aplicación y de la implementación CGN del proveedor.
CGNAT reduce el número de direcciones IPv4 públicas necesarias por abonado mediante el uso compartido de direcciones, pero no crea nuevo espacio IPv4 público. Los proveedores siguen necesitando IPv4 pública para el lado del CGN orientado a Internet y para los servicios que requieren direccionamiento público directo.
2022-01-27 09:22:30
ipv4Si quiere poseer una dirección IPv4, tendrá que comprársela al propietario existente. Sin embargo, comprar una dirección IPv4 tiene sus ventajas y sus riesgos.
2021-03-16 05:04:47
ipv4Las direcciones IP virtuales son direcciones IP que no están conectadas a una computadora específica. Por lo tanto, pueden rotar entre los nodos del clúster de Content Gateway.
2022-05-06 09:19:48
IPv4Las direcciones del Protocolo de Internet (IP) se hicieron para distinguir un gadget en una organización IP excepcionalmente, por ejemplo, la web pública.
2021-02-25 12:03:02
ipaddressLas diferencias se pueden dividir en tres puntos principales, que son la dirección, la configuración y el protocolo de mensajes de control de Internet.
Envíe el tamaño de su bloque, perfil de despliegue, contexto ASN, plazos o consulta de vendedor. LARUS responderá con una ruta comercial directa, no con lenguaje genérico de broker.
