La 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) que utilizan los ISP en el diseño de redes IPv4 . Con CGNAT, 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 de tipo middlebox integrados en la red del operador de red, lo que permite compartir pequeños grupos de direcciones públicas entre muchos usuarios finales. Esto, en esencia, repite la función NAT tradicional de las instalaciones del cliente a nivel del ISP.
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 a través de tres dominios de direccionamiento IPv4 diferentes: la red privada del 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.
Las técnicas CGNAT se utilizaron por primera vez en 2000 [ cita requerida ] para satisfacer la necesidad inmediata de un gran número de direcciones IPv4 en las implementaciones del Servicio General de Radio por Paquetes (GPRS) de redes móviles. Las implementaciones estimadas de CGNAT aumentaron de 1200 en 2014 a 3400 en 2016, y el 28,85 % de las implementaciones estudiadas parecen estar en redes de operadores móviles. [3]
Espacio de direcciones compartido
Si un ISP implementa un CGN y utiliza el espacio de direcciones RFC 1918 para numerar las puertas de enlace de los clientes, surge el riesgo de colisión de direcciones y, por lo tanto, de fallas de enrutamiento, cuando la red del cliente ya utiliza un espacio de direcciones RFC 1918.
Esto impulsó a algunos ISP a desarrollar una política dentro del Registro Americano de Números de Internet (ARIN) para asignar nuevo espacio de direcciones privadas para los CGN, pero ARIN defirió al 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 para fines técnicos (según RFC 2860).
La IETF publicó el RFC 6598, que detalla un espacio de direcciones compartidas para su uso en implementaciones de CGN de ISP que pueden manejar los mismos prefijos de red que aparecen tanto en 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. La asignación de más espacio de direcciones IPv4 privadas para dispositivos NAT podría prolongar la transición a IPv6. [ cita requerida ]
Ventajas
Maximiza el uso del espacio limitado de direcciones IPv4 públicas.
Desventajas
Los críticos del NAT de nivel de operador argumentan los siguientes aspectos:
Puede crear un cuello de botella en el rendimiento que limite la escalabilidad .
La NAT de nivel de operador generalmente impide que los clientes del ISP utilicen el reenvío de puertos , porque la traducción de direcciones de red (NAT) generalmente se implementa asignando los puertos de los dispositivos NAT en la red a otros puertos en la interfaz externa. Esto se hace para que el enrutador pueda asignar las respuestas al dispositivo correcto; en las redes NAT de nivel de operador, aunque el enrutador en el extremo del consumidor pueda estar 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.
En los casos en que se prohíbe el tráfico en función de las direcciones IP, un sistema puede bloquear el tráfico de un usuario que envía spam al prohibir la dirección IP del usuario. Si resulta que ese usuario está detrás de una NAT de nivel de operador, otros usuarios que comparten la misma dirección pública con el spammer serán bloqueados inadvertidamente. [7] Esto puede crear problemas para los administradores de foros y wikis que intentan abordar las acciones disruptivas de un solo usuario malintencionado que comparte una dirección IP con usuarios legítimos.
^ S. Jiang; D. Guo; B. Carpenter (junio de 2011), Una NAT incremental de nivel de operador (CGN) para la transición a IPv6 , ISSN 2070-1721, RFC 6264
^ Chris Grundemann (14 de febrero de 2011). "NAT444 (CGN/LSN) y lo que rompe".
^ Livadariu, Ioana; Benson, Karyn; Elmokashfi, Ahmed; Dhamdhere, Amogh; Dainotti, Alberto (2018). Inferir la implementación de NAT de nivel de operador en la naturaleza (PDF) . IEEE INFOCOM 2018 - Conferencia IEEE sobre comunicaciones informáticas. Honolulu, Hawai, Estados Unidos. págs. 2249–2257. doi : 10.1109/INFOCOM.2018.8486223 . Consultado el 22 de julio de 2021 .
^ "Re: espacio de direcciones compartido... ¡una realidad!". Archivado desde el original el 7 de junio de 2012. Consultado el 13 de septiembre de 2012 .
^ Chris Grundemann (13 de marzo de 2012). "100.64.0.0/10 – Espacio de transición compartido".
^ RFC 7021 - Evaluación del impacto de la NAT de nivel de operador en las aplicaciones de red
^ ab "Informe final del MC/159 sobre las implicaciones de los traductores de direcciones de red de nivel de operador". Ofcom . 2013-04-15 . Consultado el 2023-10-17 .
Enlaces externos
RFC 6888: Requisitos comunes para NAT de nivel de operador (CGN)
Un análisis multiperspectivo de la implementación de NAT de nivel de operador (mayo de 2016)
CGN :: Observaciones y recomendaciones (abril de 2012)
Comprensión de la NAT de nivel de operador (septiembre de 2009)
