NAT de nivel de operador

La traducción de direcciones de red ( NAT) de nivel de operador ( CGN o CGNAT ) (también conocida como NAT a gran escala , LSN ) es un tipo de traducción de direcciones de red (NAT) utilizada por los proveedores de servicios de Internet (ISP) en el diseño de redes IPv4 . Con CGN, los sitios finales, en particular las redes residenciales, se configuran con direcciones de red privadas que se traducen a direcciones IPv4 públicas mediante dispositivos traductores de direcciones de red (NAT ) intermedios integrados en la red del operador, lo que permite compartir pequeños grupos de direcciones públicas entre muchos usuarios finales. Esto reproduce esencialmente la función tradicional de NAT en las instalaciones del cliente a nivel del ISP.

La NAT de nivel de operador se utiliza a menudo para mitigar el agotamiento de direcciones IPv4 . ^{[ 1 ]}

Un escenario de uso de CGN se ha denominado NAT444 , ^{[ 2 ]} porque algunas conexiones de clientes a servicios de Internet en la Internet pública pasarían por tres dominios de direcciones IPv4 diferentes: la red privada del propio cliente, la red privada del operador y la Internet pública.

Otro escenario de CGN es Dual-Stack Lite , en el que la red del operador utiliza IPv6 y, por lo tanto, solo se necesitan dos dominios de direccionamiento IPv4. CGN también puede aplicarse mediante traductores NAT64 a nivel de ISP en combinación con 464XLAT , lo que elimina por completo IPv4 en la red residencial.

Las técnicas CGN se utilizaron por primera vez en el año 2000 para satisfacer la necesidad inmediata de un gran número de direcciones IPv4 en las implementaciones de redes móviles del Servicio General de Radio por Paquetes (GPRS). Se estima que las implementaciones CGN aumentaron de 1200 en 2014 a 3400 en 2016, y el 28,85 % de las implementaciones estudiadas se encontraban en redes de operadores móviles. ^{[ 3 ]}

Si un ISP implementa una CGN y utiliza el espacio de direcciones RFC 1918 para numerar las puertas de enlace de los clientes, el riesgo de colisión de direcciones y, por lo tanto, de fallos de enrutamiento, surge cuando la red del cliente ya utiliza un espacio de direcciones RFC 1918 .  

Esto llevó a algunos proveedores de servicios de Internet (ISP) a desarrollar una política dentro del Registro Estadounidense de Números de Internet (ARIN) para asignar nuevo espacio de direcciones privadas para los CGN, pero ARIN consultó con el IETF antes de implementar la política, indicando que el asunto no era un problema típico de asignación, sino una reserva de direcciones con fines técnicos (según RFC 2860).

La IETF publicó la RFC 6598 , que detalla un espacio de direcciones compartido para su uso en implementaciones CGN de ​​ISP que puede manejar los mismos prefijos de red que ocurren tanto en las interfaces de entrada como de salida. ARIN devolvió el espacio de direcciones a la Autoridad de Números Asignados de Internet (IANA) para esta asignación. ^{[ 4 ]} El bloque de direcciones asignado es 100.64.0.0/10, es decir, direcciones IP desde 100.64.0.0 hasta 100.127.255.255. ^{[ 5 ]} 

Los dispositivos que evalúan si una dirección IPv4 es pública deben actualizarse para reconocer el nuevo espacio de direcciones. Asignar más espacio de direcciones IPv4 privadas para dispositivos NAT podría posponer la necesidad de migrar a IPv6.

• Maximiza el uso del espacio limitado de direcciones IPv4 públicas.

• Como cualquier forma de NAT, rompe el principio de extremo a extremo . ^{[ 6 ]}
• Tiene importantes problemas de seguridad y fiabilidad , debido a que es un sistema con estado .
• Esto no resuelve el problema del agotamiento de direcciones IPv4 cuando se necesita una dirección IP pública, como por ejemplo en el alojamiento web.
• Puede generar un cuello de botella en el rendimiento que limite la escalabilidad .
• Por lo general, impide que los clientes del ISP utilicen el reenvío de puertos , ya que el NAT se suele implementar asignando los puertos de los dispositivos NAT de la red a otros puertos de la interfaz externa. Esto se hace para que el enrutador pueda asignar las respuestas al dispositivo correcto; en las redes NAT de grado operador, aunque el enrutador del consumidor esté configurado para el reenvío de puertos, el "enrutador maestro" del ISP, que ejecuta el CGN, bloqueará este reenvío de puertos porque el puerto real no sería el puerto configurado por el consumidor. ^{[ 7 ]} Para superar la desventaja anterior, el Protocolo de Control de Puertos (PCP) se ha estandarizado en el RFC 6887; la adopción por parte de los operadores ha sido lenta .
• En los casos de bloqueo de tráfico basado en direcciones IP, un sistema podría bloquear el tráfico de un usuario que envía spam bloqueando su dirección IP. Si dicho usuario se encuentra detrás de un NAT de nivel de operador, otros usuarios que compartan la misma dirección pública con el remitente de spam también se verán bloqueados inadvertidamente. ^{[ 7 ]} Esto puede generar problemas para los administradores de foros y wikis que intentan abordar las acciones perjudiciales de un único usuario malicioso que comparte una dirección IP con usuarios legítimos.
• Los servicios de transmisión de contenido multimedia pueden considerar la actividad de CGN como equivalente al tráfico de VPN o de uso compartido de cuentas . Estos servicios suelen bloquear o prohibir el acceso a los usuarios de VPN por incumplir los términos de servicio, bajo la suposición de que acceden a contenido desde una región más barata para intentar pagar menos por el servicio. Asimismo, bloquean el tráfico de uso compartido de cuentas para varios hogares o usuarios que acceden al contenido con una sola cuenta.
• CGN interfiere con el funcionamiento de varios mecanismos de transición a IPv6 .
• Los críticos de CGN podrían argumentar que la implementación de CGN desvía recursos técnicos y de gestión que se podrían emplear mejor en la promoción y el desarrollo de la adopción de IPv6.

• Mapeo de direcciones y puertos
• NAT64
• DNS64
• 464XLAT

• RFC 6888 : Requisitos comunes para NAT de grado operador (CGN) 
• Análisis desde múltiples perspectivas del despliegue de NAT de nivel de operador (mayo de 2016)
• CGN  :: Observaciones y recomendaciones (abril de 2012)
• Comprensión de la tecnología NAT de nivel de operador (septiembre de 2009)