Gestione dell'esaurimento degli IP pubblici negli alloggi per studenti

Questa guida fornisce un riferimento tecnico definitivo per gli architetti di rete che implementano Carrier-Grade NAT (CGNAT) e Port Address Translation (PAT) per gestire l'esaurimento di IPv4 in ambienti densi di alloggi per studenti e WiFi multi-tenant. Copre l'architettura NAT444, lo spazio di indirizzi condiviso RFC 6598, il dimensionamento dell'allocazione dei blocchi di porte (Port Block Allocation), le strategie di logging conformi al GDPR e un percorso di migrazione IPv6 dual-stack. La guida è essenziale per qualsiasi operatore che gestisce centinaia o migliaia di dispositivi concorrenti su un pool di IP pubblici limitato, fornendo indicazioni di configurazione pratiche, casi di studio reali e analisi del ROI.

📖 10 minuti di lettura📝 2,500 parole🔧 3 esempi pratici❓ 3 domande di esercitazione📚 10 definizioni chiave

Ascolta questa guida

Visualizza trascrizione 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.

Punti chiave

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

Riepilogo Esecutivo

Con l'accelerazione dell'esaurimento degli indirizzi IPv4, i responsabili IT e gli architetti di rete in ambienti multi-tenant densi — come alloggi per studenti, ospitalità e grandi luoghi pubblici — affrontano significative sfide operative. Un singolo blocco di alloggi per studenti con 1.000 residenti può generare oltre 7.000 dispositivi IP-connessi concorrenti. Le architetture standard di Port Address Translation (PAT) falliscono a questa scala, portando all'esaurimento delle porte, a connessioni interrotte e a un'esperienza utente degradata.

Questa guida di riferimento tecnico illustra l'architettura e l'implementazione di Carrier-Grade NAT (CGNAT) utilizzando il modello NAT444 per gestire l'esaurimento degli IP. Sfruttando lo spazio di indirizzi condiviso RFC 6598 e implementando una strategica Port Block Allocation (PBA), gli operatori di rete possono raggiungere un'elevata densità di abbonati — fino a 128 utenti per IP pubblico — mantenendo la conformità con il GDPR e le normative sull'intercettazione legale. Per le strutture che utilizzano piattaforme come Guest WiFi e WiFi Analytics , una robusta architettura CGNAT garantisce connettività stabile e una raccolta dati accurata senza la spesa in conto capitale per l'acquisto di blocchi IPv4 aggiuntivi.

Approfondimento Tecnico

Il Problema della Scala negli Alloggi per Studenti

La densità di dispositivi negli alloggi moderni per studenti è diversa da quasi qualsiasi altro ambiente di rete gestito. Un singolo residente tipicamente connette uno smartphone, un laptop, una smart TV, una console di gioco e almeno un dispositivo smart home. Con cinque-sette dispositivi per occupante, uno sviluppo da 1.000 posti letto presenta un carico di sessioni concorrenti che supera di gran lunga quello di un hotel di dimensioni comparabili. La sfida è aggravata dai modelli di utilizzo: le ore di punta serali (18:00–23:00) vedono attività ad alta larghezza di banda quasi simultanee tra giochi, streaming video e social media, tutti i quali mantengono connessioni in background persistenti.

Lo spazio di indirizzi IPv4 è effettivamente esaurito a livello di Regional Internet Registry (RIR). RIPE NCC, che gestisce le allocazioni in Europa e Medio Oriente, ha raggiunto la sua politica di allocazione finale /8 nel 2019. L'acquisizione di blocchi IPv4 pubblici aggiuntivi sul mercato aperto costa ora tra $40 e $60 per indirizzo — una spesa in conto capitale proibitiva per qualsiasi operatore che gestisce centinaia di sottoreti.

Le Limitazioni del PAT Standard

Nelle implementazioni tradizionali a sito singolo, Port Address Translation (PAT) mappa un'intera LAN privata (spazio RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) a un singolo indirizzo IP pubblico. Un singolo indirizzo IPv4 ha 65.535 porte disponibili tra TCP e UDP. Sebbene sufficiente per un piccolo ufficio, negli alloggi per studenti densi, la proliferazione di applicazioni in background — sincronizzazione cloud, piattaforme di messaggistica, servizi di streaming — significa che un singolo utente può facilmente consumare centinaia di porte contemporaneamente. Quando il router edge PAT esaurisce le sue porte disponibili, le nuove richieste di sessione vengono silenziosamente scartate. Ciò si manifesta come timeout delle applicazioni, chiamate VoIP fallite e un aumento delle richieste al servizio di assistenza.

L'Architettura CGNAT (NAT444)

Per scalare oltre le limitazioni del NAT a livello singolo, le reti aziendali devono adottare un'architettura NAT di livello carrier, in particolare il modello NAT444. Il nome si riferisce ai tre livelli di spazio di indirizzi IPv4 coinvolti nella catena di traduzione.

Livello 1 — Livello CPE / Access Point: Ai dispositivi degli abbonati vengono assegnati indirizzi IP privati dallo spazio RFC 1918 (es. 192.168.x.x). L'access point o Customer Premises Equipment (CPE) esegue la prima traduzione NAT.

Livello 2 — Gateway CGNAT: Il CPE traduce gli indirizzi privati RFC 1918 nello spazio di indirizzi condiviso RFC 6598 (100.64.0.0/10). Questo spazio intermedio è specificamente riservato per l'uso tra l'infrastruttura del fornitore di servizi e il gateway CGNAT. L'utilizzo di RFC 6598 — piuttosto che un'altra gamma RFC 1918 — previene la sovrapposizione di indirizzi e i conflitti di routing in ambienti multi-tenant complessi.

Livello 3 — Internet Pubblico: Il gateway CGNAT esegue la traduzione finale dagli indirizzi RFC 6598 a un indirizzo IPv4 pubblico condiviso. Questo è l'indirizzo visibile ai servizi esterni.

Allocazione dei Blocchi di Porte: La Decisione di Progettazione Critica

La scelta di configurazione più significativa in un'implementazione CGNAT è la strategia di allocazione delle porte. Esistono due approcci:

Allocazione Dinamica delle Porte (DPA): Le porte vengono assegnate su base per sessione da un pool condiviso. Questo massimizza l'efficienza di utilizzo delle porte ma genera una voce di log per ogni singola configurazione e chiusura di sessione — creando un onere di conformità e infrastruttura su larga scala.

Allocazione dei Blocchi di Porte (PBA): Un blocco contiguo di porte viene assegnato a ciascun abbonato al momento dell'avvio della prima sessione. Il blocco rimane allocato fino alla scadenza della sessione dell'abbonato. Questo approccio genera log solo all'assegnazione e al rilascio del blocco, riducendo il volume dei log fino al 98%.

Parametro di Configurazione	Valore Raccomandato	Motivazione
Porte per abbonato (dimensione blocco PBA)	500	Sufficiente per l'utilizzo moderno multi-app senza esaurimento del pool
Max abbonati per IP pubblico	128	Mantiene oltre 500 porte per utente con 64.000 porte utilizzabili per IP
Max sessioni concorrenti per abbonato	2.000	Impedisce a un singolo dispositivo compromesso di esaurire il blocco
Timeout sessione (TCP stabilito)	7.440 secondi (RFC 5382)	Si allinea con le raccomandazioni IETF per il comportamento NAT
Timeout sessione (UDP)	300 seconds	Impedisce che le mappature UDP obsolete consumino spazio nelle porte

Benchmark di settore: NFWare, un fornitore CGNAT specializzato con implementazioni in oltre 100 ISP, raccomanda un massimo di 128 abbonati per IP pubblico con 500 porte assegnate per abbonato. Superare questa soglia — ad esempio, spingendo a 256 abbonati per IP con 250 porte ciascuno — aumenta significativamente il rischio di interruzioni di sessione durante i carichi di punta.

Dual-Stack IPv6 come percorso di migrazione a lungo termine

Il CGNAT è una strategia di mitigazione, non una soluzione permanente. La traiettoria architetturale corretta è un'implementazione Dual-Stack: eseguire IPv6 nativamente insieme a IPv4 con CGNAT. I dispositivi moderni e i principali CDN (Google, Netflix, Meta, Cloudflare) preferiscono fortemente IPv6 quando disponibile. In un ambiente dual-stack ben configurato, il 60-70% del traffico totale può essere scaricato su IPv6, riducendo drasticamente il carico sul pool CGNAT IPv4 e prolungandone la vita utile effettiva.

Per gli ambienti sanitari e di trasporto dove il supporto dei dispositivi legacy è critico, il dual-stack fornisce anche un percorso di migrazione pulito: i dispositivi compatibili con IPv6 passano nativamente, mentre i dispositivi legacy solo IPv4 continuano a operare tramite CGNAT senza alcuna interruzione per l'utente.

Guida all'implementazione

Fase 1: Verifica dell'allocazione IP corrente e della densità dei dispositivi

Prima di implementare il CGNAT, stabilire una base di riferimento. Raccogliere i seguenti dati dal sistema di gestione della rete esistente:

Numero massimo di dispositivi concorrenti per sottorete
Sessioni medie e di picco per dispositivo
Percentuale di utilizzo corrente dell'IP pubblico
Configurazioni di timeout NAT esistenti

Questi dati informano direttamente il dimensionamento del blocco PBA e i requisiti del pool di IP pubblici.

Fase 2: Progettazione della rete intermedia RFC 6598

Allocare il blocco 100.64.0.0/10 per la rete intermedia di livello carrier. Pianificare il subnetting in base alla topologia del campus — tipicamente un /24 o /23 per edificio o segmento di livello di accesso. Assicurarsi che l'infrastruttura di routing non divulghi i prefissi RFC 6598 a internet pubblico o ai partner di peering.

Fase 3: Implementazione e configurazione del gateway CGNAT

Il gateway CGNAT è tipicamente un'appliance hardware dedicata o una funzione di rete virtualizzata (VNF) in esecuzione su hardware server commodity. Parametri di configurazione chiave:

Pool NAT: Assegnare il blocco IPv4 pubblico al pool NAT. Assicurarsi che il pool sia dimensionato per il rapporto abbonato-IP desiderato.
Configurazione PBA: Impostare la dimensione del blocco a 500 porte. Configurare il numero massimo di blocchi per abbonato a 1 (con l'opzione di espandere a 2 se un abbonato esaurisce il blocco iniziale, piuttosto che aumentare la dimensione del blocco base).
Registrazione: Configurare l'output syslog al SIEM. Con PBA, ogni voce di log registra: IP interno dell'abbonato, IP pubblico assegnato, inizio del blocco di porte assegnato, fine del blocco, timestamp di allocazione e timestamp di rilascio.
Limiti di sessione: Applicare un massimo di 2.000 sessioni concorrenti per abbonato per prevenire abusi.

Fase 4: Integrazione con il livello di identità e autenticazione

Negli ambienti che utilizzano piattaforme Guest WiFi , l'autenticazione del captive portal deve avvenire al o prima del confine NAT di Livello 1. Ciò garantisce che il provider di identità possa mappare accuratamente gli indirizzi MAC e le credenziali utente a specifici indirizzi IP interni prima che il traffico venga aggregato nel pool CGNAT. La piattaforma di Purple gestisce questo a livello di access point, mantenendo un binding utente-IP pulito che persiste attraverso la catena di traduzione NAT.

Per le implementazioni di accesso senza password — come descritto in Come un assistente Wi-Fi abilita l'accesso senza password nel 2026 — si applica lo stesso principio: il binding dell'identità deve essere stabilito a monte del gateway CGNAT per garantire un'attribuzione accurata della sessione.

Fase 5: Configurazione Dual-Stack IPv6

Abilitare IPv6 su tutti gli access point e distribuire un prefisso /64 per VLAN tramite DHCPv6 o SLAAC. Annunciare le rotte IPv6 tramite il provider upstream. Verificare che il traffico CDN principale (Google, Netflix, YouTube) si risolva in record AAAA e venga instradato tramite IPv6 prima di ridurre la dimensione del pool NAT IPv4.

Migliori Pratiche

Implementare NAT Deterministico ove possibile. Il NAT Deterministico utilizza una mappatura algoritmica tra l'indirizzo IP interno dell'abbonato e il suo IP pubblico e blocco di porte assegnati. Poiché la mappatura è matematicamente calcolabile, non è necessario mantenere o registrare una tabella di sessione — la mappatura può essere decodificata su richiesta per scopi di intercettazione legale. Questo è lo standard d'oro per le implementazioni attente alla conformità.

Distribuire il carico del gateway CGNAT. Evitare di centralizzare tutto il traffico CGNAT attraverso una singola appliance. Distribuire i gateway nel campus o tra gli edifici per prevenire un singolo punto di fallimento. I gateway distribuiti mitigano anche il rischio di reputazione IP: se un IP pubblico nel pool viene segnalato da un CDN per schemi di traffico sospetti (il problema CAPTCHA), solo una frazione di utenti viene colpita.

Monitorare proattivamente la reputazione IP. Iscriversi a feed di reputazione IP (es. Spamhaus, SURBL) e monitorare gli IP del pool NAT pubblico. Mantenere un pool di riserva di IP puliti da ruotare se un indirizzo attivo viene inserito in blacklist. Questo è particolarmente importante negli alloggi per studenti, dove un piccolo numero di utenti potrebbe impegnarsi in attività che attivano segnalazioni di abuso.

Applicare limiti di sessione per abbonato. Un limite rigido di 2.000 sessioni concorrenti per abbonato impedisce a un singolo dispositivo compromesso — ad esempio, uno che partecipa a un attacco di amplificazione DDoS — di esaurire l'intero blocco di porte assegnato a quell'IP pubblico. Per maggiori informazioni sul monitoraggio delle prestazioni di rete, consultare la nostra guida su Come misurare la potenza e la copertura del segnale WiFi .

Allinearsi con IEEE 802.1X per il controllo degli accessil. L'implementazione dell'autenticazione basata su porta IEEE 802.1X a livello di accesso garantisce che solo i dispositivi autenticati ricevano assegnazioni IP. Ciò riduce il rischio che dispositivi non autorizzati consumino le allocazioni di porte e fornisce una chiara traccia di controllo per scopi di intercettazione legale.

Risoluzione dei problemi e mitigazione del rischio

L'onere della registrazione e della conformità

Nel Regno Unito e in Europa, ai sensi del GDPR e dell'Investigatory Powers Act 2016, gli operatori di rete devono essere in grado di risalire da un indirizzo IP pubblico e un numero di porta a un utente specifico in un determinato momento. Questo è un obbligo legale non negoziabile.

Il rischio: Con il CGNAT dinamico, la registrazione di ogni configurazione e chiusura di sessione genera terabyte di dati syslog al giorno. Un'implementazione per 1.000 utenti con allocazione dinamica può produrre 500 milioni di voci di log al giorno. Ciò sovraccarica l'infrastruttura SIEM, aumenta i costi di archiviazione e rende impraticabile l'indagine forense.

La mitigazione: L'allocazione di blocchi di porte (PBA) riduce il volume di registrazione fino al 98%. Con PBA, si registrano solo gli eventi di assegnazione e rilascio del blocco — tipicamente due voci di log per utente per sessione, anziché centinaia o migliaia. Assicurati che il tuo SIEM conservi questi log per un minimo di 12 mesi per conformarsi ai requisiti di conservazione dei dati del Regno Unito.

Il problema del CAPTCHA e della reputazione IP

Quando 128 utenti condividono un singolo IP pubblico, il volume di traffico aggregato può attivare limitazioni di velocità o protezioni anti-bot sui principali siti web. reCAPTCHA di Google, la gestione dei bot di Cloudflare e sistemi simili utilizzano euristiche basate su IP che possono classificare erroneamente un IP CGNAT condiviso come fonte di bot.

La mitigazione: Distribuisci il tuo pool CGNAT su più IP pubblici. Monitora proattivamente i punteggi di reputazione. Considera l'implementazione di DNS-over-HTTPS (DoH) o DNS-over-TLS (DoT) per prevenire problemi di reputazione basati su DNS. Educa gli utenti che i prompt CAPTCHA occasionali sono un comportamento noto negli ambienti IP condivisi.

Problemi di compatibilità delle applicazioni

Certe applicazioni — in particolare i protocolli peer-to-peer, alcune implementazioni VoIP e le piattaforme di gioco legacy — si basano su mappature di porte coerenti o sull'avvio di connessioni in entrata. Queste possono non funzionare correttamente con il doppio NAT.

La mitigazione: Per il VoIP, assicurati che il tuo gateway CGNAT supporti ALG (Application Layer Gateway) per SIP. Per il gaming, considera l'implementazione di un proxy UPnP o di una VLAN di gioco dedicata con un pool NAT separato e meno denso. Per gli ambienti retail dove i sistemi POS (point-of-sale) richiedono connettività in entrata, posiziona tali dispositivi su una VLAN separata che bypassa completamente il livello CGNAT.

ROI e impatto sul business

Risparmi sulle spese in conto capitale

L'implementazione del CGNAT offre risparmi immediati e sostanziali sulle spese in conto capitale (CapEx). Con un prezzo di mercato di $50 per indirizzo IPv4, un'università con 5.000 posti letto che richiede un rapporto 1:1 dispositivo-IP dovrebbe acquistare circa 35.000 indirizzi IP — un costo di $1,75 milioni. Implementando il CGNAT con un rapporto 128:1, la stessa implementazione richiede meno di 300 IP pubblici, riducendo il costo di acquisizione degli IP a circa $15.000.

Anche tenendo conto del costo dell'hardware del gateway CGNAT o delle funzioni di rete virtualizzate (tipicamente $20.000–$80.000 per un'implementazione su scala campus), il risparmio netto è sostanziale.

Riduzione delle spese operative

La connettività stabile riduce direttamente il carico di lavoro dell'helpdesk. Gli eventi di esaurimento delle porte — la principale modalità di guasto del PAT standard su larga scala — generano un volume sproporzionato di ticket di supporto. Un'implementazione CGNAT ben configurata con limiti di sessione appropriati e PBA elimina questa modalità di guasto, riducendo il volume dell'helpdesk relativo alla rete di un stimato 30–40%.

Differenziazione competitiva negli alloggi per studenti

Nel competitivo mercato degli alloggi per studenti, la qualità della rete è un criterio di selezione primario per i potenziali inquilini. Gli operatori che possono dimostrare una connettività coerente e ad alta velocità — convalidata tramite dashboard WiFi Analytics che mostrano l'uptime, la qualità della sessione e le metriche di densità dei dispositivi — ottengono tariffe di affitto premium e raggiungono un'occupazione più elevata. Questa stabilità dell'infrastruttura è anche la base per l'implementazione di servizi avanzati basati sulla posizione, come evidenziato in Purple Launches Offline Maps Mode for Seamless, Secure Navigation to WiFi Hotspots .

Caso di studio 1: Residenze universitarie da 800 posti letto

Un'università del Regno Unito che gestisce residenze universitarie da 800 posti letto stava riscontrando problemi cronici di connettività durante le ore di punta serali. L'indagine ha rivelato che la loro configurazione PAT a livello singolo, utilizzando una sottorete pubblica /29 (6 IP utilizzabili), esauriva le porte disponibili entro le 19:30 ogni sera. L'operatore ha implementato una soluzione CGNAT con PBA (500 porte per abbonato, 128 abbonati per IP), ha effettuato l'upgrade a una sottorete pubblica /27 (30 IP utilizzabili) e ha abilitato l'IPv6 dual-stack. Le metriche post-implementazione hanno mostrato una riduzione del 94% degli eventi di esaurimento delle porte, una riduzione del 38% dei ticket dell'helpdesk relativi alla rete e una riduzione del 65% del volume dei log CGNAT rispetto a un pilot iniziale di allocazione dinamica. Il tasso di offload IPv6 ha raggiunto il 62% entro 60 giorni dall'implementazione.

Caso di studio 2: Operatore di alloggi per studenti appositamente costruiti (PBSA) con 1.200 camere

Un operatore privato di PBSA che gestisce tre siti in due città del Regno Unito aveva bisogno di standardizzare la propria architettura di rete prima dell'apertura di un quarto sito. La loro infrastruttura esistente utilizzava un mix di NAT a livello singolo e segmentazione VLAN ad hoc, senza una strategia di logging coerente. È stata implementata una soluzione CGNAT con NAT deterministico su tutti e tre i siti, consentendo una mappatura abbonato-IP matematicamente calcolabile senza alcun overhead di logging delle sessioni. Questo approccio ha soddisfatto il team legale dell'operatore per quanto riguarda la conformità all'intercettazione legale, ha eliminato il costo di archiviazione SIEM per i log delle sessioni e ha fornito un modello di architettura coerente per il quarto sito. L'operatore ha anche integrato la piattaforma Guest WiFi di Purple per l'autenticazione del captive portal, con il binding dell'identità stabilito a monte di til gateway CGNAT per garantire un'attribuzione accurata dell'utente nei report di analisi.

Definizioni chiave

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.

Esempi pratici

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.

Commento dell'esaminatore: 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.

Commento dell'esaminatore: 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.

Commento dell'esaminatore: 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.

Domande di esercitazione

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.

Suggerimento: 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.

Visualizza risposta modello

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.

Suggerimento: 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.

Visualizza risposta modello

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.

Suggerimento: 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.

Visualizza risposta modello

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.