Gestión del agotamiento de IP públicas en residencias de estudiantes

Esta guía proporciona una referencia técnica definitiva para arquitectos de red que implementan Carrier-Grade NAT (CGNAT) y Port Address Translation (PAT) para gestionar el agotamiento de IPv4 en entornos densos de residencias de estudiantes y WiFi multiusuario. Cubre la arquitectura NAT444, el espacio de direcciones compartidas RFC 6598, el dimensionamiento de Port Block Allocation, estrategias de registro compatibles con GDPR y una ruta de migración a IPv6 de doble pila. La guía es esencial para cualquier operador que gestione cientos o miles de dispositivos concurrentes en un grupo de IP públicas restringido, proporcionando orientación de configuración práctica, estudios de casos reales y análisis de ROI.

📖 10 min de lectura📝 2,500 palabras🔧 3 ejemplos prácticos❓ 3 preguntas de práctica📚 10 definiciones clave

Escuchar esta guía

Ver transcripción del podcast

Hello, and welcome to this technical briefing from Purple. I'm your host, and today we're tackling a critical infrastructure challenge for multi-tenant networks: Managing Public IP Exhaustion in Student Housing.

If you're a network architect, CTO, or IT manager operating dense environments — whether that's student accommodation, hospitality, or large retail complexes — you know the pain of IPv4 depletion. You have thousands of concurrent devices, a shrinking pool of public IPs, and the constant pressure to maintain high throughput and seamless connectivity. Today, we're diving deep into Carrier-Grade NAT, or CGNAT, Port Address Translation, and how to architect a scalable solution that doesn't compromise performance or compliance.

Let's set the context. In a typical student housing block, a single resident brings a smartphone, a laptop, a smart TV, a gaming console, and maybe a smart speaker. That's five to seven devices per user. Multiply that by five hundred or a thousand beds, and you're looking at a massive concurrent session load. Standard NAT or PAT — Port Address Translation — often breaks down at this scale. Why? Because a single public IP only has sixty-five thousand, five hundred and thirty-five TCP and UDP ports available. When thousands of devices are opening multiple background sessions for cloud sync, messaging apps, and streaming, port exhaustion happens fast. The result? Dropped connections, degraded user experience, and a spike in helpdesk tickets.

This is where CGNAT, specifically NAT four-four-four, comes in. Unlike standard single-level NAT, CGNAT introduces a second layer of translation. The subscriber devices get private IPs from RFC 1918 space, like 192.168.x.x. These are translated by the access point or CPE to a shared carrier-grade address space — specifically RFC 6598, which is the 100.64.0.0 slash ten block. Finally, the CGNAT gateway translates these to public internet IPs.

Let's get into the technical deep-dive. How do we deploy this effectively?

First, Port Block Allocation, or PBA. This is the cornerstone of a stable CGNAT deployment. Instead of dynamically assigning ports one by one — which creates a massive logging overhead and fragments the port space — you assign a contiguous block of ports to each subscriber.

Industry best practice, and what we typically recommend for dense environments, is allocating around five hundred ports per subscriber. This strikes the right balance. It's enough to handle modern web applications without starving the pool. At five hundred ports per user, a single public IPv4 address can support up to one hundred and twenty-eight subscribers. If you push it further, say to two hundred and fifty-six subscribers, you're dropping the port allocation to two-fifty, which significantly increases the risk of session drops during peak usage — like evening study hours or weekend gaming sessions.

Now, let's talk about implementation recommendations and pitfalls.

Pitfall number one: Ignoring Session Logging and Compliance. In the UK and Europe, under GDPR and lawful intercept regulations, you must be able to trace a public IP and port back to a specific user at a specific time. If you're using dynamic port allocation, your CGNAT gateway will generate a log entry for every single session setup and teardown. At scale, this is terabytes of syslog data per day. It will crush your logging infrastructure.

The solution? Again, Port Block Allocation. With PBA, you only log when a block is assigned to a user and when it's released. This reduces logging volume by up to ninety-eight percent, making compliance manageable and cost-effective.

Pitfall number two: The CAPTCHA problem. When one hundred and twenty-eight users share a single public IP, major content delivery networks and search engines might flag the traffic volume as suspicious, treating it like a botnet. Users start getting endless CAPTCHA prompts. To mitigate this, ensure your CGNAT gateways are distributed, and rotate the public IP pools if a specific address gets blacklisted.

Let's move to a rapid-fire Q and A based on common questions we hear from lead architects.

Question: Should we just skip CGNAT and move straight to IPv6?
Answer: In an ideal world, yes. But the reality of student housing is that many legacy devices — older gaming consoles, cheap smart plugs — still only support IPv4. The recommended architecture is a Dual-Stack deployment. Run IPv6 natively alongside IPv4 with CGNAT. This offloads up to sixty to seventy percent of traffic — like YouTube, Netflix, and Facebook — directly to IPv6, drastically reducing the load on your IPv4 NAT pools.

Question: How does this impact our Purple WiFi deployment?
Answer: It integrates seamlessly. Purple acts as the identity provider and handles the authentication and analytics layer. The underlying IP routing, whether dual-stack or CGNAT, is transparent to the Purple portal. Just ensure your RADIUS accounting and syslog are correctly correlated if you need to trace user sessions for compliance.

To summarise: IPv4 exhaustion is a reality, but it's manageable.

One: Use NAT four-four-four with RFC 6598 shared address space.
Two: Implement Port Block Allocation at roughly five hundred ports per subscriber.
Three: Keep your subscriber-to-IP ratio at or below one hundred and twenty-eight to one.
Four: Deploy IPv6 Dual-Stack to offload traffic.
Five: Ensure your logging strategy aligns with lawful intercept requirements without overwhelming your SIEM.

That concludes our technical briefing on Managing Public IP Exhaustion in Student Housing. For detailed architecture diagrams, configuration examples, and more insights on Multi-Tenant WiFi, be sure to check out the full technical reference guide on the Purple website. Thank you for listening.

Conclusiones clave

✓Standard PAT fails in dense student housing because a single public IP's 65,535 ports are exhausted by thousands of concurrent devices — CGNAT (NAT444) solves this by introducing a second translation layer using RFC 6598 shared address space.
✓The 128:1 rule is the critical capacity planning constraint: never exceed 128 subscribers per public IPv4 address when using a 500-port PBA block size, as exceeding this ratio risks session drops during peak load.
✓Port Block Allocation (PBA) is both a performance optimisation and a compliance requirement — it reduces CGNAT logging volume by up to 98%, making GDPR and lawful intercept obligations operationally feasible without overwhelming SIEM infrastructure.
✓IPv6 dual-stack is the mandatory companion to CGNAT: achieving 60% IPv6 offload effectively halves the load on the IPv4 NAT pool, extending its capacity without additional IP acquisition.
✓Captive portal and identity provider authentication (e.g., Purple Guest WiFi) must be placed upstream of the CGNAT gateway to maintain a reliable user-to-IP binding for analytics and lawful intercept compliance.
✓Deterministic NAT is the gold standard for compliance: algorithmic mapping eliminates session logging entirely while satisfying lawful intercept requirements, and should be the default choice when the CGNAT platform supports it.
✓The CapEx case for CGNAT is compelling — a 128:1 subscriber ratio reduces the required public IP block for a 5,000-bed campus from a /18 to a /26, avoiding up to $1.7 million in IPv4 acquisition costs at current market rates.

Resumen ejecutivo

A medida que el agotamiento de las direcciones IPv4 se acelera, los gerentes de TI y los arquitectos de red en entornos multiusuario densos —como residencias de estudiantes, hospitality y grandes espacios públicos— se enfrentan a importantes desafíos operativos. Un solo bloque de alojamiento para estudiantes con 1.000 residentes puede generar más de 7.000 dispositivos IP conectados simultáneamente. Las arquitecturas estándar de Port Address Translation (PAT) fallan a esta escala, lo que lleva al agotamiento de puertos, conexiones caídas y una experiencia de usuario degradada.

Esta guía de referencia técnica describe la arquitectura y la implementación de Carrier-Grade NAT (CGNAT) utilizando el modelo NAT444 para gestionar el agotamiento de IP. Al aprovechar el espacio de direcciones compartidas RFC 6598 e implementar una Port Block Allocation (PBA) estratégica, los operadores de red pueden lograr una alta densidad de suscriptores —hasta 128 usuarios por IP pública— manteniendo el cumplimiento de GDPR y las regulaciones de interceptación legal. Para los lugares que utilizan plataformas como Guest WiFi y WiFi Analytics , una arquitectura CGNAT robusta garantiza una conectividad estable y una recopilación de datos precisa sin el gasto de capital de adquirir bloques IPv4 adicionales.

Análisis técnico en profundidad

El problema de la escala en las residencias de estudiantes

La densidad de dispositivos en el alojamiento estudiantil moderno es diferente a casi cualquier otro entorno de red gestionado. Un solo residente suele conectar un smartphone, un portátil, un Smart TV, una consola de juegos y al menos un dispositivo inteligente para el hogar. Con cinco a siete dispositivos por ocupante, un desarrollo de 1.000 camas presenta una carga de sesiones concurrentes que empequeñece a un hotel de tamaño comparable. El desafío se agrava por los patrones de uso: las horas pico de la tarde (18:00–23:00) ven una actividad de alto ancho de banda casi simultánea en juegos, streaming de vídeo y redes sociales, todo lo cual mantiene conexiones persistentes en segundo plano.

El espacio de direcciones IPv4 está efectivamente agotado a nivel de Registro Regional de Internet (RIR). RIPE NCC, que gestiona las asignaciones en Europa y Oriente Medio, alcanzó su política de asignación final de /8 en 2019. La adquisición de bloques IPv4 públicos adicionales en el mercado abierto ahora cuesta entre 40 y 60 dólares por dirección, un CapEx prohibitivo para cualquier operador que gestione cientos de subredes.

Las limitaciones de la PAT estándar

En las implementaciones tradicionales de un solo sitio, la Port Address Translation (PAT) asigna una LAN privada completa (espacio RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) a una única dirección IP pública. Una única dirección IPv4 tiene 65.535 puertos disponibles en TCP y UDP. Si bien es suficiente para una pequeña oficina, en residencias de estudiantes densas, la proliferación de aplicaciones en segundo plano —sincronización en la nube, plataformas de mensajería, servicios de streaming— significa que un solo usuario puede consumir fácilmente cientos de puertos simultáneamente. Cuando el router de borde PAT agota sus puertos disponibles, las nuevas solicitudes de sesión se descartan silenciosamente. Esto se manifiesta como tiempos de espera de aplicaciones, llamadas VoIP fallidas y un aumento en los tickets de soporte técnico.

La arquitectura CGNAT (NAT444)

Para escalar más allá de las limitaciones de la NAT de un solo nivel, las redes empresariales deben adoptar una arquitectura Carrier-Grade NAT, específicamente el modelo NAT444. El nombre se refiere a las tres capas de espacio de direcciones IPv4 involucradas en la cadena de traducción.

Nivel 1 — Capa de CPE / Punto de acceso: A los dispositivos de los suscriptores se les asignan direcciones IP privadas del espacio RFC 1918 (por ejemplo, 192.168.x.x). El punto de acceso o Customer Premises Equipment (CPE) realiza la primera traducción NAT.

Nivel 2 — Gateway CGNAT: El CPE traduce las direcciones privadas RFC 1918 al espacio de direcciones compartidas RFC 6598 (100.64.0.0/10). Este espacio intermedio está específicamente reservado para su uso entre la infraestructura del proveedor de servicios y el gateway CGNAT. El uso de RFC 6598 —en lugar de otro rango RFC 1918— evita la superposición de direcciones y los conflictos de enrutamiento en entornos multiusuario complejos.

Nivel 3 — Internet pública: El gateway CGNAT realiza la traducción final de las direcciones RFC 6598 a una dirección IPv4 pública compartida. Esta es la dirección visible para los servicios externos.

Port Block Allocation: La decisión de diseño crítica

La elección de configuración más trascendental en una implementación de CGNAT es la estrategia de asignación de puertos. Existen dos enfoques:

Dynamic Port Allocation (DPA): Los puertos se asignan por sesión desde un grupo compartido. Esto maximiza la eficiencia de utilización de puertos, pero genera una entrada de registro para cada configuración y cierre de sesión, creando una carga de cumplimiento e infraestructura a escala.

Port Block Allocation (PBA): Se asigna un bloque contiguo de puertos a cada suscriptor al iniciar su primera sesión. El bloque permanece asignado hasta que expira la sesión del suscriptor. Este enfoque genera registros solo en la asignación y liberación del bloque, reduciendo el volumen de registros hasta en un 98%.

Parámetro de configuración	Valor recomendado	Razón
Puertos por suscriptor (tamaño de bloque PBA)	500	Suficiente para el uso moderno de múltiples aplicaciones sin agotamiento del grupo
Máx. suscriptores por IP pública	128	Mantiene más de 500 puertos por usuario con 64.000 puertos utilizables por IP
Máx. sesiones concurrentes por suscriptor	2.000	Evita que un solo dispositivo comprometido agote el bloque
Tiempo de espera de sesión (TCP establecido)	7.440 segundos (RFC 5382)	Se alinea con las recomendaciones de la IETF para el comportamiento NAT
Tiempo de espera de sesión (UDP)	300 segnds	Evita que las asignaciones UDP obsoletas consuman espacio de puertos

Referencia del sector: NFWare, un proveedor especializado en CGNAT con implementaciones en más de 100 ISP, recomienda un máximo de 128 suscriptores por IP pública con 500 puertos asignados por suscriptor. Superar este umbral —por ejemplo, aumentar a 256 suscriptores por IP con 250 puertos cada uno— incrementa significativamente el riesgo de caídas de sesión durante la carga máxima.

IPv6 Dual-Stack como ruta de migración a largo plazo

CGNAT es una estrategia de mitigación, no una solución permanente. La trayectoria arquitectónica correcta es una implementación Dual-Stack: ejecutar IPv6 de forma nativa junto con IPv4 con CGNAT. Los dispositivos modernos y los principales CDN (Google, Netflix, Meta, Cloudflare) prefieren encarecidamente IPv6 cuando está disponible. En un entorno dual-stack bien configurado, el 60-70% del tráfico total puede descargarse a IPv6, reduciendo drásticamente la carga en el pool de CGNAT IPv4 y extendiendo su vida útil efectiva.

Para entornos de sanidad y transporte donde el soporte de dispositivos heredados es crítico, el dual-stack también proporciona una ruta de migración limpia: los dispositivos compatibles con IPv6 realizan la transición de forma nativa, mientras que los dispositivos heredados solo con IPv4 continúan operando a través de CGNAT sin ninguna interrupción para el usuario.

Guía de implementación

Paso 1: Audite su asignación de IP actual y densidad de dispositivos

Antes de implementar CGNAT, establezca una línea de base. Recopile los siguientes datos de su sistema de gestión de red existente:

Recuento máximo de dispositivos concurrentes por subred
Sesiones promedio y pico por dispositivo
Porcentaje actual de utilización de IP pública
Configuraciones de tiempo de espera de NAT existentes

Estos datos informan directamente sobre el tamaño de su bloque PBA y los requisitos del pool de IP públicas.

Paso 2: Diseñe la red intermedia RFC 6598

Asigne el bloque 100.64.0.0/10 para la red intermedia de grado de operador. Planifique el subnetting para que coincida con la topología de su campus —típicamente un /24 o /23 por edificio o segmento de capa de acceso. Asegúrese de que su infraestructura de enrutamiento no filtre prefijos RFC 6598 a la internet pública o a socios de interconexión.

Paso 3: Implemente y configure el Gateway CGNAT

El gateway CGNAT es típicamente un dispositivo de hardware dedicado o una función de red virtualizada (VNF) que se ejecuta en hardware de servidor comercial. Parámetros clave de configuración:

Pool NAT: Asigne su bloque IPv4 público al pool NAT. Asegúrese de que el pool esté dimensionado para su relación suscriptor-IP objetivo.
Configuración PBA: Establezca el tamaño del bloque en 500 puertos. Configure el máximo de bloques por suscriptor en 1 (con la opción de expandir a 2 si un suscriptor agota su bloque inicial, en lugar de aumentar el tamaño del bloque base).
Registro: Configure la salida de syslog a su SIEM. Con PBA, cada entrada de registro anota: IP interna del suscriptor, IP pública asignada, inicio del bloque de puertos asignado, fin del bloque, marca de tiempo de asignación y marca de tiempo de liberación.
Límites de sesión: Imponga un máximo de 2.000 sesiones concurrentes por suscriptor para evitar abusos.

Paso 4: Integre con la capa de identidad y autenticación

En entornos que utilizan plataformas de Guest WiFi , la autenticación del Captive Portal debe ocurrir en o antes del límite NAT de Nivel 1. Esto asegura que el proveedor de identidad pueda mapear con precisión las direcciones MAC y las credenciales de usuario a direcciones IP internas específicas antes de que el tráfico se agregue al pool de CGNAT. La plataforma de Purple gestiona esto a nivel de punto de acceso, manteniendo una vinculación limpia de usuario a IP que persiste a través de la cadena de traducción NAT.

Para implementaciones de acceso sin contraseña —como se describe en Cómo un asistente de Wi-Fi habilita el acceso sin contraseña en 2026 — se aplica el mismo principio: la vinculación de identidad debe establecerse antes del gateway CGNAT para asegurar una atribución precisa de la sesión.

Paso 5: Configure IPv6 Dual-Stack

Habilite IPv6 en todos los puntos de acceso y distribuya un prefijo /64 por VLAN a través de DHCPv6 o SLAAC. Anuncie las rutas IPv6 a través de su proveedor de upstream. Verifique que el tráfico principal de CDN (Google, Netflix, YouTube) se resuelva a registros AAAA y se enrute a través de IPv6 antes de reducir el tamaño de su pool NAT IPv4.

Mejores prácticas

Implemente NAT Determinístico Siempre que sea Posible. El NAT Determinístico utiliza un mapeo algorítmico entre la dirección IP interna del suscriptor y su IP pública asignada y bloque de puertos. Dado que el mapeo es matemáticamente computable, no es necesario mantener o registrar una tabla de sesiones —el mapeo puede ser reconstruido bajo demanda para fines de interceptación legal. Este es el estándar de oro para implementaciones conscientes del cumplimiento.

Distribuya la Carga del Gateway CGNAT. Evite centralizar todo el tráfico CGNAT a través de un único dispositivo. Distribuya los gateways por todo el campus o entre edificios para evitar un único punto de fallo. Los gateways distribuidos también mitigan el riesgo de reputación de IP: si una IP pública en el pool es marcada por un CDN por patrones de tráfico sospechosos (el problema CAPTCHA), solo una fracción de los usuarios se ve afectada.

Monitorice la Reputación de IP de Forma Proactiva. Suscríbase a fuentes de reputación de IP (por ejemplo, Spamhaus, SURBL) y monitorice las IPs de su pool NAT público. Mantenga un pool de reserva de IPs limpias para rotar si una dirección activa es incluida en una lista negra. Esto es particularmente importante en residencias de estudiantes, donde un pequeño número de usuarios puede participar en actividades que activan banderas de abuso.

Aplique Límites de Sesión por Suscriptor. Un límite estricto de 2.000 sesiones concurrentes por suscriptor evita que un solo dispositivo comprometido —por ejemplo, uno que participe en un ataque de amplificación DDoS— agote todo el bloque de puertos asignado a esa IP pública. Para más información sobre la monitorización del rendimiento de la red, consulte nuestra guía sobre Cómo medir la intensidad y cobertura de la señal WiFi .

Alínee con IEEE 802.1X para el Control de Accesol. La implementación de autenticación basada en puertos IEEE 802.1X en la capa de acceso garantiza que solo los dispositivos autenticados reciban asignaciones de IP. Esto reduce el riesgo de que dispositivos no autorizados consuman asignaciones de puertos y proporciona un registro de auditoría claro para fines de interceptación legal.

Resolución de problemas y mitigación de riesgos

La carga de registro y cumplimiento

En el Reino Unido y Europa, bajo GDPR y la Ley de Poderes de Investigación de 2016, los operadores de red deben poder rastrear una dirección IP pública y un número de puerto hasta un usuario específico en una marca de tiempo específica. Esta es una obligación legal no negociable.

El riesgo: Con CGNAT dinámico, el registro de cada configuración y cierre de sesión genera terabytes de datos de syslog al día. Una implementación de 1.000 usuarios con asignación dinámica puede producir 500 millones de entradas de registro diarias. Esto sobrecarga la infraestructura SIEM, aumenta los costes de almacenamiento y hace que la investigación forense sea poco práctica.

La mitigación: La asignación de bloques de puertos (PBA) reduce el volumen de registro hasta en un 98%. Con PBA, solo se registran los eventos de asignación y liberación de bloques, normalmente dos entradas de registro por usuario por sesión, en lugar de cientos o miles. Asegúrese de que su SIEM retenga estos registros durante un mínimo de 12 meses para cumplir con los requisitos de retención de datos del Reino Unido.

El problema de CAPTCHA y la reputación de IP

Cuando 128 usuarios comparten una única IP pública, el volumen de tráfico agregado puede activar la limitación de velocidad o las protecciones anti-bot en los principales sitios web. reCAPTCHA de Google, la gestión de bots de Cloudflare y sistemas similares utilizan heurísticas basadas en IP que pueden clasificar erróneamente una IP CGNAT compartida como una fuente de bot.

La mitigación: Distribuya su pool de CGNAT entre múltiples IPs públicas. Supervise proactivamente las puntuaciones de reputación. Considere la implementación de DNS-over-HTTPS (DoH) o DNS-over-TLS (DoT) para prevenir problemas de reputación basados en DNS. Eduque a los usuarios de que las solicitudes ocasionales de CAPTCHA son un comportamiento conocido en entornos de IP compartida.

Problemas de compatibilidad de aplicaciones

Ciertas aplicaciones —particularmente protocolos peer-to-peer, algunas implementaciones de VoIP y plataformas de juegos heredadas— dependen de asignaciones de puertos consistentes o de la iniciación de conexiones entrantes. Estas pueden fallar bajo doble NAT.

La mitigación: Para VoIP, asegúrese de que su gateway CGNAT sea compatible con ALG (Application Layer Gateway) para SIP. Para juegos, considere implementar un proxy UPnP o una VLAN de juegos dedicada con un pool NAT separado y menos denso. Para entornos de retail donde los sistemas de punto de venta requieren conectividad entrante, coloque esos dispositivos en una VLAN separada que omita completamente la capa CGNAT.

ROI e impacto empresarial

Ahorro en gastos de capital (CapEx)

La implementación de CGNAT ofrece ahorros inmediatos y sustanciales en CapEx. A una tasa de mercado de 50 $ por dirección IPv4, una universidad con 5.000 camas que requiera una relación dispositivo-IP de 1:1 necesitaría adquirir aproximadamente 35.000 direcciones IP, con un coste de 1,75 millones de dólares. Al implementar CGNAT con una relación de 128:1, la misma implementación requiere menos de 300 IPs públicas, reduciendo el coste de adquisición de IP a aproximadamente 15.000 $.

Incluso teniendo en cuenta el coste del hardware del gateway CGNAT o las funciones de red virtualizadas (normalmente entre 20.000 y 80.000 $ para una implementación a escala de campus), el ahorro neto es sustancial.

Reducción de gastos operativos (OpEx)

La conectividad estable reduce directamente la sobrecarga del servicio de asistencia. Los eventos de agotamiento de puertos —el modo de fallo principal de PAT estándar a escala— generan un volumen desproporcionado de tickets de soporte. Una implementación de CGNAT bien configurada con límites de sesión y PBA adecuados elimina este modo de fallo, reduciendo el volumen de asistencia técnica relacionado con la red en un 30-40% estimado.

Diferenciación competitiva en residencias de estudiantes

En el competitivo mercado de alojamiento para estudiantes, la calidad de la red es un criterio de selección principal para los posibles inquilinos. Los operadores que pueden demostrar una conectividad consistente y de alto rendimiento —validada a través de paneles de WiFi Analytics que muestran el tiempo de actividad, la calidad de la sesión y las métricas de densidad de dispositivos— obtienen tarifas de alquiler premium y logran una mayor ocupación. Esta estabilidad de la infraestructura es también la base para implementar servicios avanzados basados en la ubicación, como se destaca en Purple Launches Offline Maps Mode for Seamless, Secure Navigation to WiFi Hotspots .

Caso práctico 1: Residencias universitarias de 800 camas

Una universidad del Reino Unido que operaba residencias de 800 camas experimentaba problemas crónicos de conectividad durante las horas pico de la tarde. La investigación reveló que su configuración PAT de un solo nivel, utilizando una subred pública /29 (6 IPs utilizables), estaba agotando los puertos disponibles a las 19:30 cada noche. El operador implementó una solución CGNAT con PBA (500 puertos por suscriptor, 128 suscriptores por IP), actualizó a una subred pública /27 (30 IPs utilizables) y habilitó IPv6 dual-stack. Las métricas posteriores a la implementación mostraron una reducción del 94% en los eventos de agotamiento de puertos, una reducción del 38% en los tickets de asistencia técnica relacionados con la red y una reducción del 65% en el volumen de registros CGNAT en comparación con un piloto inicial de asignación dinámica. La tasa de descarga de IPv6 alcanzó el 62% en los 60 días posteriores a la implementación.

Caso práctico 2: Operador de alojamiento para estudiantes construido a propósito (PBSA) de 1.200 habitaciones

Un operador privado de PBSA que gestionaba tres sitios en dos ciudades del Reino Unido necesitaba estandarizar su arquitectura de red antes de la apertura de un cuarto sitio. Su infraestructura existente utilizaba una mezcla de NAT de un solo nivel y segmentación VLAN ad hoc, sin una estrategia de registro consistente. Se implementó una implementación de CGNAT con NAT determinista en los tres sitios, lo que permitió un mapeo de suscriptor a IP matemáticamente computable sin ninguna sobrecarga de registro de sesión. Este enfoque satisfizo al equipo legal del operador en cuanto al cumplimiento de la interceptación legal, eliminó el coste de almacenamiento SIEM para los registros de sesión y proporcionó una plantilla de arquitectura consistente para el cuarto sitio. El operador también integró la plataforma Guest WiFi de Purple para la autenticación de captive portal, con la vinculación de identidad establecida antes de la tla pasarela CGNAT para garantizar una atribución de usuario precisa en los informes de análisis.

Definiciones clave

CGNAT (Carrier-Grade NAT)

A network architecture in which an operator performs Network Address Translation at a centralised gateway, enabling multiple subscribers to share a single public IPv4 address. Defined in RFC 6264 and RFC 6888. Also known as Large-Scale NAT (LSN) or CGN.

IT teams encounter CGNAT when a single public IP is insufficient to serve all devices on a network. In student housing, CGNAT is the primary mechanism for managing IPv4 exhaustion without purchasing additional public address space.

NAT444

A specific CGNAT topology involving three layers of IPv4 address space: subscriber private addresses (RFC 1918), carrier-grade shared addresses (RFC 6598), and public internet addresses. The name refers to the three IPv4 networks traversed.

NAT444 is the standard architecture for CGNAT deployments in multi-tenant environments. Network architects must understand the three-layer model to correctly design the intermediate network and avoid address overlap.

RFC 6598 Shared Address Space

The 100.64.0.0/10 IPv4 address block (100.64.0.0 to 100.127.255.255) reserved by IANA for use in the intermediate network between a CPE and a CGNAT gateway. This space is not routable on the public internet and is specifically designed to prevent address conflicts in NAT444 deployments.

IT teams must use RFC 6598 — not RFC 1918 — for the intermediate CGNAT network. Using RFC 1918 for this segment creates address overlap risks when the same RFC 1918 ranges are used in subscriber networks.

Port Block Allocation (PBA)

A CGNAT port assignment strategy in which a contiguous block of ports (e.g., 500 ports) is assigned to each subscriber for the duration of their session, rather than allocating ports individually per connection. Defined in RFC 7422.

PBA is the recommended approach for GDPR-compliant CGNAT deployments. It reduces logging overhead by up to 98% compared to dynamic port allocation, making lawful intercept compliance operationally feasible at scale.

Deterministic NAT

A CGNAT configuration in which the mapping between a subscriber's internal IP address and their assigned public IP and port block is computed algorithmically, without maintaining a session table. The mapping is reversible mathematically, enabling subscriber identification without log retrieval.

Deterministic NAT is the gold standard for compliance-conscious deployments. It eliminates logging overhead entirely while satisfying lawful intercept requirements, as the subscriber can be identified from a public IP, port, and timestamp using the known algorithm.

PAT (Port Address Translation)

A form of Network Address Translation in which multiple private IP addresses are mapped to a single public IP address by differentiating connections using unique source port numbers. Also referred to as NAT overload or many-to-one NAT.

PAT is the standard single-level NAT used in most enterprise edge routers. It is the predecessor to CGNAT and is insufficient for dense multi-tenant environments due to port exhaustion at scale.

Session Table

A data structure maintained by a NAT gateway that records the mapping between internal (private) IP address and port, and external (public) IP address and port, for each active connection. The session table is the primary memory and processing resource consumed by CGNAT.

Session table sizing is a critical capacity planning parameter for CGNAT gateways. A 1,000-subscriber deployment with 2,000 max sessions per subscriber requires a session table capacity of at least 2 million entries. Undersizing the session table causes connection failures.

Dual-Stack

A network configuration in which both IPv4 and IPv6 protocols are simultaneously active on the same network infrastructure and end devices. Devices with dual-stack capability will prefer IPv6 for connections to IPv6-capable destinations.

Dual-stack is the recommended transition strategy for CGNAT deployments. By offloading IPv6-capable traffic to the native IPv6 path, dual-stack reduces the load on the IPv4 CGNAT pool and provides a migration path toward an IPv6-primary network.

RFC 1918 Private Address Space

The three IPv4 address ranges reserved for private network use: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. These addresses are not routable on the public internet and are used for internal network addressing.

RFC 1918 addresses are used for subscriber device addressing in CGNAT deployments. Network architects must ensure RFC 1918 ranges used in subscriber networks do not overlap with those used in the intermediate CGNAT network — which is why RFC 6598 is used for the intermediate layer.

Lawful Intercept

The legally authorised interception of communications by law enforcement agencies. In the UK, governed by the Investigatory Powers Act 2016. Network operators must be able to identify the subscriber associated with a specific public IP address, port, and timestamp upon receipt of a lawful intercept request.

Lawful intercept compliance is the primary driver of CGNAT logging requirements. Operators must retain sufficient logs to identify subscribers from public IP and port data. PBA and Deterministic NAT are the two architectures that make this feasible at scale without overwhelming logging infrastructure.

Ejemplos prácticos

A 600-bed student accommodation block currently uses a single /29 public subnet (6 usable IPs) with standard PAT. During evening peak hours (19:00–23:00), users report widespread connectivity failures. The network team has confirmed port exhaustion on the PAT router. The operator has a budget for CGNAT gateway hardware but cannot acquire additional public IPs beyond a /27 (30 usable IPs). Design a CGNAT deployment that eliminates the port exhaustion issue and supports future growth to 900 beds.

Step 1 — Baseline Assessment: With 600 beds at 5 devices per occupant, peak concurrent device count is approximately 3,000. At 500 ports per subscriber (PBA), each public IP supports 128 subscribers. With 30 usable IPs in the /27, the theoretical maximum subscriber capacity is 3,840 — sufficient for 900 beds at 4.3 devices per occupant. Step 2 — RFC 6598 Intermediate Network: Allocate 100.64.0.0/20 for the intermediate carrier-grade network, providing 4,096 addresses for CPE-to-CGNAT gateway traffic. Subnet per building wing: 100.64.0.0/24, 100.64.1.0/24, etc. Step 3 — CGNAT Gateway Sizing: Deploy a CGNAT gateway with a session table capacity of at least 768,000 entries (3,000 subscribers × 2,000 max sessions per subscriber, with 20% headroom). Configure PBA with 500-port blocks. Set max blocks per subscriber to 1, with overflow to 2 blocks permitted for subscribers exceeding 500 concurrent sessions. Step 4 — IPv6 Dual-Stack: Enable IPv6 on all access points. Distribute /64 prefixes via SLAAC. Target 60% IPv6 offload within 90 days, which effectively reduces the IPv4 CGNAT load to 1,200 concurrent IPv4 subscribers — well within the /27 capacity. Step 5 — Logging: Configure syslog to SIEM with PBA block assignment/release events only. Retain logs for 12 months minimum. Step 6 — Session Limits: Enforce 2,000 max sessions per subscriber at the CGNAT gateway to prevent abuse.

Comentario del examinador: This solution correctly identifies that the /27 (30 IPs × 128 subscribers per IP = 3,840 capacity) is sufficient for the 900-bed growth target, avoiding the need for additional IP acquisition. The IPv6 dual-stack component is critical — without it, the IPv4 pool would be under sustained pressure. The PBA configuration at 500 ports per subscriber is the industry-standard recommendation and directly addresses the port exhaustion failure mode. The session table sizing calculation (3,000 × 2,000 × 1.2 headroom) is a practical engineering approach. An alternative approach — purchasing additional IPv4 space — would cost approximately $150,000 for a /24 on the open market and is not justified when CGNAT achieves the same outcome at a fraction of the cost.

A PBSA operator has deployed CGNAT across a 1,000-bed site using dynamic port allocation. Their legal team has flagged that the current logging approach generates 400GB of syslog data per day, which is overwhelming the SIEM and making lawful intercept requests from law enforcement impractical to fulfil. Redesign the logging strategy to meet UK lawful intercept obligations while reducing log volume to a manageable level.

Step 1 — Migrate to Port Block Allocation: Replace dynamic port allocation with PBA at 500 ports per subscriber. This immediately reduces log events from one-per-session to one-per-block-assignment and one-per-block-release. For a 1,000-user deployment with an average of 3 block assignment/release cycles per user per day, this generates approximately 6,000 log entries per day — a reduction of over 99% from the dynamic allocation baseline. Step 2 — Log Schema: Ensure each PBA log entry captures: (a) subscriber internal IP address, (b) assigned public IP address, (c) assigned port block start and end, (d) timestamp of block assignment (UTC), (e) timestamp of block release (UTC), (f) subscriber identifier (MAC address or RADIUS username). Step 3 — Deterministic NAT Option: If the CGNAT platform supports it, migrate to Deterministic NAT. This eliminates logging entirely for routine operations, as the mapping is mathematically computable. Retain PBA logs only for non-deterministic overflow cases. Step 4 — Retention Policy: Retain logs for 12 months in a tamper-evident log store (e.g., write-once S3-compatible object storage). Implement access controls so that log retrieval for lawful intercept requests requires dual authorisation. Step 5 — Incident Response Procedure: Document the procedure for responding to lawful intercept requests, including the formula for reverse-computing the subscriber from a public IP, port, and timestamp under Deterministic NAT.

Comentario del examinador: The key insight here is that dynamic port allocation is the root cause of the logging problem, not CGNAT itself. The migration to PBA is the primary intervention. The reduction from 400GB/day to approximately 1MB/day (6,000 log entries) is realistic and aligns with published industry benchmarks. The Deterministic NAT option is the optimal long-term solution but requires platform support — not all CGNAT appliances implement it. The dual-authorisation requirement for log access is a GDPR best practice, ensuring that lawful intercept log retrieval is auditable. This approach satisfies both the Investigatory Powers Act 2016 requirements and GDPR data minimisation principles.

A university IT team reports that students are experiencing frequent CAPTCHA challenges and rate-limiting from Google, Netflix, and gaming platforms. Investigation reveals that 200 students are sharing a single public IP address through CGNAT. The team has been told that acquiring more public IPs is not possible in the short term. What immediate mitigations can be implemented without changing the IP allocation?

Step 1 — Reduce Subscriber Density: The 200:1 ratio is the primary cause. Even without additional public IPs, review whether the CGNAT pool is being used efficiently. Ensure IPv6 dual-stack is fully enabled — if 60% of traffic offloads to IPv6, the effective IPv4 subscriber count drops to approximately 80 per IP, well within the 128:1 recommended threshold. Step 2 — IP Rotation: Implement a rotation policy for the public IP pool. If the CGNAT gateway supports it, configure periodic rotation of the public IP assigned to each subscriber group. This prevents any single IP from accumulating a persistent negative reputation. Step 3 — DNS Optimisation: Ensure the DNS resolvers provided to clients return AAAA records preferentially. Many CAPTCHA triggers are DNS-based — if a client resolves a service to an IPv4 address unnecessarily, it routes through CGNAT when it could use IPv6 natively. Step 4 — Session Timeout Tuning: Reduce UDP session timeouts from the default (often 300 seconds) to 60 seconds for non-DNS UDP traffic. This frees up port space faster and reduces the apparent session volume from the perspective of external services. Step 5 — Communicate with Affected Platforms: For persistent blacklisting issues, submit delisting requests to major IP reputation databases (Spamhaus, SURBL). Document that the IP is a shared CGNAT address serving a legitimate educational institution.

Comentario del examinador: This scenario tests the candidate's ability to mitigate the IP reputation problem without the primary lever of additional IP acquisition. The IPv6 dual-stack solution is the most impactful intervention and should be the first recommendation. The DNS AAAA preference configuration is a subtle but effective optimisation that many operators overlook. Session timeout tuning is a valid short-term measure but carries risk — overly aggressive timeouts can break stateful applications. The delisting request process is a legitimate operational procedure but is reactive rather than preventive. The correct long-term answer remains reducing the subscriber-to-IP ratio to 128:1 or below.

Preguntas de práctica

Q1. A 2,000-bed student accommodation campus has a /26 public subnet (62 usable IPs). The network team is planning a CGNAT deployment. Calculate: (a) the maximum number of subscribers supportable at the recommended 128:1 ratio, (b) the total port capacity available, (c) the recommended PBA block size, and (d) whether the existing /26 is sufficient or whether additional IPs are required.

Sugerencia: Start with the total usable IPs in a /26, then apply the 128:1 subscriber ratio. Compare the result against the 2,000-bed device count at a realistic devices-per-occupant ratio. Consider IPv6 dual-stack offload in your final recommendation.

Ver respuesta modelo

A /26 provides 62 usable public IPs. At 128 subscribers per IP, the maximum IPv4 CGNAT capacity is 62 × 128 = 7,936 subscribers. At 5 devices per occupant, 2,000 beds generates approximately 10,000 concurrent devices. Without IPv6, the /26 is insufficient (7,936 < 10,000). However, with IPv6 dual-stack achieving 60% offload, the effective IPv4 load drops to approximately 4,000 devices — well within the /26 capacity of 7,936. The recommended PBA block size is 500 ports per subscriber. Total port capacity: 62 IPs × 64,000 usable ports = 3,968,000 ports. At 500 ports per subscriber: 3,968,000 / 500 = 7,936 subscribers maximum. Recommendation: Deploy CGNAT with PBA at 500 ports/subscriber, enable IPv6 dual-stack as a prerequisite, and the existing /26 is sufficient. If IPv6 offload cannot be guaranteed above 50%, acquire an additional /27 as a buffer.

Q2. A CGNAT deployment at a 500-bed student hall is generating compliance concerns. The operator's legal team has received a lawful intercept request from law enforcement for a specific public IP address (203.0.113.45), port 51432, at timestamp 2025-11-15 21:47:33 UTC. The CGNAT gateway is configured with dynamic port allocation. The SIEM contains 180 days of logs but the forensic team reports that locating the specific subscriber from the logs is taking over 4 hours per request. Identify the root cause and propose a remediation that reduces response time to under 15 minutes.

Sugerencia: The 4-hour response time is a symptom of the logging architecture, not a data retention problem. Consider what information is logged under dynamic allocation versus PBA, and how Deterministic NAT would change the response process entirely.

Ver respuesta modelo

Root cause: Dynamic port allocation generates one log entry per session. With 500 users × hundreds of sessions per user per hour, the SIEM contains millions of log entries per day. Locating a single entry by IP, port, and timestamp requires a full-text search across potentially billions of records — hence the 4-hour response time. Remediation Option 1 (PBA): Migrate to Port Block Allocation. With PBA, the log entry for port 51432 would record the block assignment (e.g., ports 51001–51500 assigned to subscriber 192.168.1.23 at 21:30:00 UTC, released at 23:15:00 UTC). A single indexed query on public IP + port range + timestamp returns the result in seconds. Estimated response time: under 2 minutes. Remediation Option 2 (Deterministic NAT): If the platform supports it, migrate to Deterministic NAT. Port 51432 can be mathematically reverse-computed to the subscriber's internal IP without any log query. Response time: under 30 seconds. Immediate action: Index the existing SIEM logs on (public_ip, port, timestamp) to reduce current response time while the PBA migration is planned.

Q3. A network architect is designing the CGNAT infrastructure for a new 800-bed PBSA development. The upstream ISP has provided a /27 public subnet and confirmed that IPv6 transit is available. The operator also wants to deploy Purple's Guest WiFi platform for captive portal authentication. Describe the correct placement of the captive portal authentication relative to the CGNAT gateway, and explain why incorrect placement creates a compliance risk.

Sugerencia: Consider what information the captive portal needs to capture (user identity, device MAC, internal IP) and at what point in the NAT translation chain this information is still available. Think about what happens to the internal IP address after it passes through the CGNAT gateway.

Ver respuesta modelo

The captive portal authentication must occur at or before the Level 1 NAT boundary — that is, at the access point or CPE layer, before traffic enters the RFC 6598 intermediate network. Correct placement: Purple's Guest WiFi platform authenticates the user at the access point. The platform records the binding: user identity → MAC address → RFC 1918 internal IP → timestamp. This binding is established before the CGNAT gateway performs its translation. The CGNAT gateway then maps the RFC 1918 IP to a public IP and port block, and the PBA log records: RFC 1918 IP → public IP → port block → timestamp. The two log records can be joined on the RFC 1918 IP and timestamp to produce a complete chain: user identity → public IP + port. Incorrect placement (captive portal after CGNAT gateway): If authentication occurs after the CGNAT gateway, the platform only sees the public IP and port — not the internal IP. Multiple users behind the same CGNAT IP are indistinguishable at this point. The platform cannot create a reliable user-to-IP binding, making lawful intercept attribution impossible and violating GDPR accountability requirements. This is the compliance risk. With Purple's architecture, the identity binding is established upstream of the CGNAT layer, ensuring accurate user attribution in both the analytics platform and the compliance log chain.