Gerir o Esgotamento de IP Público em Alojamento Universitário

Este guia fornece uma referência técnica definitiva para arquitetos de rede que implementam Carrier-Grade NAT (CGNAT) e Port Address Translation (PAT) para gerir o esgotamento de IPv4 em ambientes densos de alojamento universitário e WiFi multi-inquilino. Abrange a arquitetura NAT444, o espaço de endereços partilhado RFC 6598, o dimensionamento da Port Block Allocation, estratégias de registo em conformidade com o GDPR e um caminho de migração IPv6 dual-stack. O guia é essencial para qualquer operador que gere centenas ou milhares de dispositivos concorrentes num pool de IP público limitado, fornecendo orientação de configuração acionável, estudos de caso reais e análise de ROI.

📖 10 min de leitura📝 2,500 palavras🔧 3 exemplos práticos❓ 3 perguntas de prática📚 10 definições principais

Ouça este guia

Ver transcrição do 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.

Principais Conclusões

✓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.

Resumo Executivo

À medida que o esgotamento de endereços IPv4 acelera, os gestores de TI e arquitetos de rede em ambientes multi-inquilino densos — como alojamento universitário, hospitality e grandes espaços públicos — enfrentam desafios operacionais significativos. Um único bloco de alojamento universitário com 1.000 residentes pode gerar mais de 7.000 dispositivos IP conectados concorrentemente. As arquiteturas padrão de Port Address Translation (PAT) falham a esta escala, levando ao esgotamento de portas, ligações perdidas e experiência do utilizador degradada.

Este guia de referência técnica descreve a arquitetura e a implementação de Carrier-Grade NAT (CGNAT) usando o modelo NAT444 para gerir o esgotamento de IP. Ao alavancar o espaço de endereços partilhado RFC 6598 e implementar a Port Block Allocation (PBA) estratégica, os operadores de rede podem alcançar alta densidade de subscritores — até 128 utilizadores por IP público — mantendo a conformidade com o GDPR e as regulamentações de interceção legal. Para locais que utilizam plataformas como Guest WiFi e WiFi Analytics , uma arquitetura CGNAT robusta garante conectividade estável e recolha de dados precisa sem o investimento de capital na compra de blocos IPv4 adicionais.

Análise Técnica Detalhada

O Problema da Escala em Alojamento Universitário

A densidade de dispositivos no alojamento universitário moderno é diferente de quase qualquer outro ambiente de rede gerido. Um único residente tipicamente conecta um smartphone, um portátil, uma smart TV, uma consola de jogos e pelo menos um dispositivo de casa inteligente. Com cinco a sete dispositivos por ocupante, um empreendimento com 1.000 camas apresenta uma carga de sessões concorrentes que supera a de um hotel de tamanho comparável. O desafio é agravado pelos padrões de utilização: as horas de pico noturnas (18:00–23:00) veem atividade de alta largura de banda quase simultânea em jogos, streaming de vídeo e redes sociais, todos os quais mantêm ligações de fundo persistentes.

O espaço de endereços IPv4 está efetivamente esgotado ao nível do Regional Internet Registry (RIR). O RIPE NCC, que gere as alocações na Europa e no Médio Oriente, atingiu a sua política final de alocação /8 em 2019. Adquirir blocos IPv4 públicos adicionais no mercado aberto custa agora entre $40 e $60 por endereço — um CapEx proibitivo para qualquer operador que gere centenas de sub-redes.

As Limitações do PAT Padrão

Em implementações tradicionais de um único site, a Port Address Translation (PAT) mapeia uma LAN privada inteira (espaço RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) para um único endereço IP público. Um único endereço IPv4 tem 65.535 portas disponíveis em TCP e UDP. Embora suficiente para um pequeno escritório, em alojamento universitário denso, a proliferação de aplicações em segundo plano — sincronização na nuvem, plataformas de mensagens, serviços de streaming — significa que um único utilizador pode facilmente consumir centenas de portas simultaneamente. Quando o router de borda PAT esgota as suas portas disponíveis, os novos pedidos de sessão são silenciosamente descartados. Isto manifesta-se como timeouts de aplicações, chamadas VoIP falhadas e um aumento nos tickets de suporte técnico.

A Arquitetura CGNAT (NAT444)

Para escalar além das limitações do NAT de nível único, as redes empresariais devem adotar uma arquitetura Carrier-Grade NAT, especificamente o modelo NAT444. O nome refere-se às três camadas de espaço de endereços IPv4 envolvidas na cadeia de tradução.

Nível 1 — Camada CPE / Ponto de Acesso: Os dispositivos dos subscritores recebem endereços IP privados do espaço RFC 1918 (por exemplo, 192.168.x.x). O ponto de acesso ou Customer Premises Equipment (CPE) realiza a primeira tradução NAT.

Nível 2 — Gateway CGNAT: O CPE traduz endereços RFC 1918 privados para o Espaço de Endereços Partilhado RFC 6598 (100.64.0.0/10). Este espaço intermédio é especificamente reservado para uso entre a infraestrutura do provedor de serviços e o gateway CGNAT. Usar o RFC 6598 — em vez de outro intervalo RFC 1918 — evita sobreposição de endereços e conflitos de encaminhamento em ambientes multi-inquilino complexos.

Nível 3 — Internet Pública: O gateway CGNAT realiza a tradução final de endereços RFC 6598 para um endereço IPv4 público partilhado. Este é o endereço visível para serviços externos.

Port Block Allocation: A Decisão Crítica de Design

A escolha de configuração mais consequente numa implementação CGNAT é a estratégia de alocação de portas. Existem duas abordagens:

Alocação Dinâmica de Portas (DPA): As portas são atribuídas por sessão a partir de um pool partilhado. Isto maximiza a eficiência da utilização das portas, mas gera uma entrada de registo para cada configuração e término de sessão — criando um ónus de conformidade e infraestrutura em escala.

Port Block Allocation (PBA): Um bloco contíguo de portas é atribuído a cada subscritor aquando da sua primeira iniciação de sessão. O bloco permanece alocado até que a sessão do subscritor expire. Esta abordagem gera registos apenas na atribuição e libertação do bloco, reduzindo o volume de registos em até 98%.

Configuration Parameter	Recommended Value	Rationale
Portas por subscritor (tamanho do bloco PBA)	500	Suficiente para uso moderno de múltiplas aplicações sem esgotamento do pool
Máx. subscritores por IP público	128	Mantém mais de 500 portas por utilizador com 64.000 portas utilizáveis por IP
Máx. sessões concorrentes por subscritor	2.000	Impede que um único dispositivo comprometido esgote o bloco
Tempo limite de sessão (TCP estabelecido)	7.440 segundos (RFC 5382)	Alinha-se com as recomendações do IETF para o comportamento NAT
Tempo limite de sessão (UDP)	300 segnds	Impede que mapeamentos UDP obsoletos consumam espaço de porta

Referência da Indústria: A NFWare, um fornecedor especializado em CGNAT com implementações em mais de 100 ISPs, recomenda um máximo de 128 subscritores por IP público com 500 portas atribuídas por subscritor. Exceder este limiar — por exemplo, aumentar para 256 subscritores por IP com 250 portas cada — aumenta significativamente o risco de quedas de sessão durante o pico de carga.

IPv6 Dual-Stack como o Caminho de Migração a Longo Prazo

O CGNAT é uma estratégia de mitigação, não uma solução permanente. A trajetória arquitetónica correta é uma implementação Dual-Stack: executar IPv6 nativamente ao lado de IPv4 com CGNAT. Dispositivos modernos e grandes CDNs (Google, Netflix, Meta, Cloudflare) preferem fortemente o IPv6 quando disponível. Num ambiente dual-stack bem configurado, 60–70% do tráfego total pode ser descarregado para IPv6, reduzindo drasticamente a carga na pool de CGNAT IPv4 e estendendo a sua vida útil efetiva.

Para ambientes de saúde e transportes onde o suporte a dispositivos legados é crítico, o dual-stack também oferece um caminho de migração limpo: dispositivos compatíveis com IPv6 fazem a transição nativamente, enquanto dispositivos legados apenas com IPv4 continuam a operar através de CGNAT sem qualquer interrupção para o utilizador.

Guia de Implementação

Passo 1: Audite a Sua Alocação de IP Atual e Densidade de Dispositivos

Antes de implementar o CGNAT, estabeleça uma linha de base. Recolha os seguintes dados do seu sistema de gestão de rede existente:

Contagem máxima de dispositivos concorrentes por sub-rede
Sessões médias e de pico por dispositivo
Percentagem de utilização atual de IP público
Configurações de tempo limite NAT existentes

Estes dados informam diretamente o dimensionamento do seu bloco PBA e os requisitos da pool de IP público.

Passo 2: Projete a Rede Intermédia RFC 6598

Aloque o bloco 100.64.0.0/10 para a rede intermédia de nível de operadora. Planeie a sub-rede para corresponder à sua topologia de campus — tipicamente um /24 ou /23 por edifício ou segmento de camada de acesso. Garanta que a sua infraestrutura de encaminhamento não divulga prefixos RFC 6598 para a internet pública ou para parceiros de peering.

Passo 3: Implemente e Configure o Gateway CGNAT

O gateway CGNAT é tipicamente um dispositivo de hardware dedicado ou uma função de rede virtualizada (VNF) a correr em hardware de servidor comercial. Parâmetros de configuração chave:

Pool NAT: Atribua o seu bloco IPv4 público à pool NAT. Garanta que a pool está dimensionada para a sua proporção alvo de subscritor por IP.
Configuração PBA: Defina o tamanho do bloco para 500 portas. Configure o máximo de blocos por subscritor para 1 (com a opção de expandir para 2 se um subscritor esgotar o seu bloco inicial, em vez de aumentar o tamanho do bloco base).
Registo: Configure a saída syslog para o seu SIEM. Com PBA, cada entrada de registo grava: IP interno do subscritor, IP público atribuído, início do bloco de portas atribuído, fim do bloco, carimbo de data/hora da alocação e carimbo de data/hora da libertação.
Limites de Sessão: Imponha um máximo de 2.000 sessões concorrentes por subscritor para prevenir abusos.

Passo 4: Integrar com a Camada de Identidade e Autenticação

Em ambientes que utilizam plataformas de Guest WiFi , a autenticação do captive portal deve ocorrer no limite NAT de Nível 1 ou antes. Isso garante que o fornecedor de identidade pode mapear com precisão endereços MAC e credenciais de utilizador para endereços IP internos específicos antes que o tráfego seja agregado na pool CGNAT. A plataforma da Purple trata disso ao nível do ponto de acesso, mantendo uma ligação limpa de utilizador a IP que persiste através da cadeia de tradução NAT.

Para implementações de acesso sem palavra-passe — conforme descrito em Como um assistente de Wi-Fi permite o acesso sem palavra-passe em 2026 — o mesmo princípio se aplica: a ligação de identidade deve ser estabelecida a montante do gateway CGNAT para garantir uma atribuição de sessão precisa.

Passo 5: Configurar IPv6 Dual-Stack

Ative o IPv6 em todos os pontos de acesso e distribua um prefixo /64 por VLAN via DHCPv6 ou SLAAC. Anuncie rotas IPv6 através do seu fornecedor a montante. Verifique se o tráfego dos principais CDNs (Google, Netflix, YouTube) está a resolver para registos AAAA e a encaminhar via IPv6 antes de reduzir o tamanho da sua pool NAT IPv4.

Melhores Práticas

Implemente NAT Determinístico Sempre que Possível. O NAT Determinístico utiliza um mapeamento algorítmico entre o endereço IP interno do subscritor e o seu IP público e bloco de portas atribuídos. Como o mapeamento é matematicamente computável, não há necessidade de manter ou registar uma tabela de sessões — o mapeamento pode ser feito por engenharia inversa a pedido para fins de interceção legal. Este é o padrão ouro para implementações conscientes da conformidade.

Distribua a Carga do Gateway CGNAT. Evite centralizar todo o tráfego CGNAT através de um único dispositivo. Distribua gateways pelo campus ou por edifícios para prevenir um único ponto de falha. Gateways distribuídos também mitigam o risco de reputação de IP: se um IP público na pool for sinalizado por um CDN por padrões de tráfego suspeitos (o problema do CAPTCHA), apenas uma fração dos utilizadores é afetada.

Monitorize a Reputação de IP Proativamente. Subscreva feeds de reputação de IP (por exemplo, Spamhaus, SURBL) e monitorize os IPs da sua pool NAT pública. Mantenha uma pool de reserva de IPs limpos para rodar se um endereço ativo for colocado na lista negra. Isto é particularmente importante em alojamentos estudantis, onde um pequeno número de utilizadores pode envolver-se em atividades que acionam sinalizadores de abuso.

Imponha Limites de Sessão por Subscritor. Um limite rígido de 2.000 sessões concorrentes por subscritor impede que um único dispositivo comprometido — por exemplo, um que participe num ataque de amplificação DDoS — esgote todo o bloco de portas atribuído a esse IP público. Para mais informações sobre a monitorização do desempenho da rede, consulte o nosso guia sobre Como Medir a Força e Cobertura do Sinal WiFi .

Alinhe com IEEE 802.1X para Controlo de Acessol. A implementação da autenticação baseada em porta IEEE 802.1X na camada de acesso garante que apenas dispositivos autenticados recebam atribuições de IP. Isto reduz o risco de dispositivos não autorizados consumirem alocações de porta e fornece um registo de auditoria limpo para fins de interceção legal.

Resolução de Problemas e Mitigação de Riscos

O Encargo do Registo e da Conformidade

No Reino Unido e na Europa, ao abrigo do GDPR e da Investigatory Powers Act 2016, os operadores de rede devem ser capazes de rastrear um endereço IP público e um número de porta até um utilizador específico num determinado momento. Esta é uma obrigação legal inegociável.

O Risco: Com CGNAT dinâmico, o registo de cada configuração e término de sessão gera terabytes de dados syslog por dia. Uma implementação para 1.000 utilizadores com alocação dinâmica pode produzir 500 milhões de entradas de registo diariamente. Isto sobrecarrega a infraestrutura SIEM, aumenta os custos de armazenamento e torna a investigação forense impraticável.

A Mitigação: A Alocação de Blocos de Porta (PBA) reduz o volume de registo em até 98%. Com PBA, regista apenas os eventos de atribuição e libertação de blocos — tipicamente duas entradas de registo por utilizador por sessão, em vez de centenas ou milhares. Certifique-se de que o seu SIEM retém estes registos por um mínimo de 12 meses para cumprir os requisitos de retenção de dados do Reino Unido.

O Problema do CAPTCHA e da Reputação de IP

Quando 128 utilizadores partilham um único IP público, o volume de tráfego agregado pode acionar a limitação de taxa ou proteções anti-bot em websites importantes. O reCAPTCHA da Google, a gestão de bots da Cloudflare e sistemas semelhantes usam heurísticas baseadas em IP que podem classificar incorretamente um IP CGNAT partilhado como uma fonte de bot.

A Mitigação: Distribua o seu pool de CGNAT por múltiplos IPs públicos. Monitorize proativamente as pontuações de reputação. Considere implementar DNS-over-HTTPS (DoH) ou DNS-over-TLS (DoT) para evitar problemas de reputação baseados em DNS. Eduque os utilizadores de que os avisos ocasionais de CAPTCHA são um comportamento conhecido em ambientes de IP partilhado.

Problemas de Compatibilidade de Aplicações

Certas aplicações — particularmente protocolos peer-to-peer, algumas implementações VoIP e plataformas de jogos legadas — dependem de mapeamentos de porta consistentes ou de iniciação de conexão de entrada. Estes podem falhar sob double NAT.

A Mitigação: Para VoIP, certifique-se de que o seu gateway CGNAT suporta ALG (Application Layer Gateway) para SIP. Para jogos, considere implementar um proxy UPnP ou uma VLAN de jogos dedicada com um pool NAT separado e menos denso. Para ambientes de retalho onde os sistemas de ponto de venda exigem conectividade de entrada, coloque esses dispositivos numa VLAN separada que ignore completamente a camada CGNAT.

ROI e Impacto no Negócio

Poupanças em Despesas de Capital

A implementação de CGNAT oferece poupanças imediatas e substanciais em CapEx. A uma taxa de mercado de $50 por endereço IPv4, uma universidade com 5.000 camas que requer uma relação dispositivo-IP de 1:1 precisaria de adquirir aproximadamente 35.000 endereços IP — um custo de $1,75 milhões. Ao implementar CGNAT com uma relação de 128:1, a mesma implementação requer menos de 300 IPs públicos, reduzindo o custo de aquisição de IP para aproximadamente $15.000.

Mesmo contabilizando o custo do hardware do gateway CGNAT ou funções de rede virtualizadas (tipicamente $20.000–$80.000 para uma implementação à escala de campus), a poupança líquida é substancial.

Redução de Despesas Operacionais

A conectividade estável reduz diretamente a sobrecarga do helpdesk. Eventos de exaustão de porta — o principal modo de falha do PAT padrão em escala — geram um volume desproporcionado de tickets de suporte. Uma implementação CGNAT bem configurada com limites de sessão apropriados e PBA elimina este modo de falha, reduzindo o volume de helpdesk relacionado com a rede em cerca de 30–40%.

Diferenciação Competitiva em Alojamento Estudantil

No competitivo mercado de alojamento estudantil, a qualidade da rede é um critério de seleção primário para potenciais inquilinos. Os operadores que conseguem demonstrar conectividade consistente e de alto débito — validada através de dashboards de WiFi Analytics que mostram o tempo de atividade, a qualidade da sessão e as métricas de densidade de dispositivos — conseguem taxas de aluguer premium e atingem maior ocupação. Esta estabilidade da infraestrutura é também a base para a implementação de serviços avançados baseados em localização, como destacado em Purple Launches Offline Maps Mode for Seamless, Secure Navigation to WiFi Hotspots .

Estudo de Caso 1: Residências Universitárias com 800 Camas

Uma universidade do Reino Unido que opera residências universitárias com 800 camas estava a experienciar problemas crónicos de conectividade durante as horas de pico da noite. A investigação revelou que a sua configuração PAT de nível único, usando uma sub-rede pública /29 (6 IPs utilizáveis), estava a esgotar as portas disponíveis até às 19:30 todas as noites. O operador implementou uma solução CGNAT com PBA (500 portas por subscritor, 128 subscritores por IP), atualizou para uma sub-rede pública /27 (30 IPs utilizáveis) e ativou o dual-stack IPv6. As métricas pós-implementação mostraram uma redução de 94% nos eventos de exaustão de porta, uma redução de 38% nos tickets de helpdesk relacionados com a rede e uma redução de 65% no volume de registos CGNAT em comparação com um piloto inicial de alocação dinâmica. A taxa de descarregamento de IPv6 atingiu 62% em 60 dias após a implementação.

Estudo de Caso 2: Operador de Alojamento Estudantil Construído de Propósito (PBSA) com 1.200 Quartos

Um operador privado de PBSA que gere três locais em duas cidades do Reino Unido precisava de padronizar a sua arquitetura de rede antes da abertura de um quarto local. A sua infraestrutura existente utilizava uma mistura de NAT de nível único e segmentação VLAN ad-hoc, sem uma estratégia de registo consistente. Foi implementada uma implementação CGNAT com NAT determinístico em todos os três locais, permitindo o mapeamento matematicamente computável de subscritor para IP sem qualquer sobrecarga de registo de sessão. Esta abordagem satisfez a equipa jurídica do operador relativamente à conformidade com a interceção legal, eliminou o custo de armazenamento SIEM para registos de sessão e forneceu um modelo de arquitetura consistente para o quarto local. O operador também integrou a plataforma Guest WiFi da Purple para autenticação de captive portal, com a vinculação de identidade estabelecida a montante de to gateway CGNAT para garantir a atribuição precisa do utilizador em relatórios de análise.

Definições Principais

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.

Exemplos Práticos

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.

Comentário do 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.

Comentário do 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.

Comentário do 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.

Perguntas de Prática

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.

Dica: 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 resposta 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.

Dica: 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 resposta 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.

Dica: 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 resposta 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.