Gestion de l'épuisement des adresses IP publiques dans les résidences étudiantes

Ce guide fournit une référence technique définitive pour les architectes réseau déployant le Carrier-Grade NAT (CGNAT) et le Port Address Translation (PAT) afin de gérer l'épuisement des adresses IPv4 dans les environnements denses de résidences étudiantes et de WiFi multi-locataires. Il couvre l'architecture NAT444, l'espace d'adressage partagé RFC 6598, le dimensionnement de l'allocation de blocs de ports (Port Block Allocation), les stratégies de journalisation conformes au GDPR et un chemin de migration IPv6 dual-stack. Le guide est essentiel pour tout opérateur gérant des centaines ou des milliers d'appareils simultanés sur un pool d'adresses IP publiques contraint, offrant des conseils de configuration exploitables, des études de cas réels et une analyse du retour sur investissement.

📖 10 min de lecture📝 2,500 mots🔧 3 exemples concrets❓ 3 questions d'entraînement📚 10 définitions clés

Écouter ce guide

Voir la transcription du 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.

Points clés à retenir

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

Résumé Exécutif

Alors que l'épuisement des adresses IPv4 s'accélère, les responsables informatiques et les architectes réseau dans les environnements multi-locataires denses — tels que les résidences étudiantes, l' hôtellerie et les grands lieux publics — sont confrontés à des défis opérationnels importants. Un seul bloc de logements étudiants avec 1 000 résidents peut générer plus de 7 000 appareils connectés IP simultanément. Les architectures standard de Port Address Translation (PAT) échouent à cette échelle, entraînant l'épuisement des ports, des connexions interrompues et une expérience utilisateur dégradée.

Ce guide de référence technique décrit l'architecture et le déploiement du Carrier-Grade NAT (CGNAT) utilisant le modèle NAT444 pour gérer l'épuisement des adresses IP. En tirant parti de l'espace d'adressage partagé RFC 6598 et en mettant en œuvre une allocation stratégique de blocs de ports (PBA), les opérateurs réseau peuvent atteindre une densité d'abonnés élevée — jusqu'à 128 utilisateurs par IP publique — tout en maintenant la conformité avec le GDPR et les réglementations d'interception légale. Pour les lieux utilisant des plateformes comme Guest WiFi et WiFi Analytics , une architecture CGNAT robuste assure une connectivité stable et une collecte de données précise sans les dépenses d'investissement liées à l'achat de blocs IPv4 supplémentaires.

Approfondissement Technique

Le Problème d'Échelle dans les Résidences Étudiantes

La densité d'appareils dans les résidences étudiantes modernes est presque unique par rapport à tout autre environnement réseau géré. Un seul résident connecte généralement un smartphone, un ordinateur portable, une smart TV, une console de jeux et au moins un appareil domestique intelligent. À raison de cinq à sept appareils par occupant, un développement de 1 000 lits présente une charge de sessions simultanées qui éclipse celle d'un hôtel de taille comparable. Le défi est aggravé par les habitudes d'utilisation : les heures de pointe du soir (18h00-23h00) voient une activité quasi simultanée à large bande passante à travers les jeux, le streaming vidéo et les médias sociaux, qui maintiennent tous des connexions d'arrière-plan persistantes.

L'espace d'adressage IPv4 est effectivement épuisé au niveau des Registres Internet Régionaux (RIR). Le RIPE NCC, qui gère les allocations en Europe et au Moyen-Orient, a atteint sa politique d'allocation finale de /8 en 2019. L'acquisition de blocs IPv4 publics supplémentaires sur le marché libre coûte désormais entre 40 et 60 dollars par adresse — une dépense d'investissement (CapEx) prohibitive pour tout opérateur gérant des centaines de sous-réseaux.

Les Limites du PAT Standard

Dans les déploiements traditionnels sur site unique, le Port Address Translation (PAT) mappe un LAN privé entier (espace RFC 1918 : 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) à une seule adresse IP publique. Une seule adresse IPv4 dispose de 65 535 ports disponibles sur TCP et UDP. Bien que suffisant pour un petit bureau, dans les résidences étudiantes denses, la prolifération des applications d'arrière-plan — synchronisation cloud, plateformes de messagerie, services de streaming — signifie qu'un seul utilisateur peut facilement consommer des centaines de ports simultanément. Lorsque le routeur de périphérie PAT épuise ses ports disponibles, les nouvelles requêtes de session sont silencieusement abandonnées. Cela se manifeste par des délais d'attente d'application, des appels VoIP échoués et une augmentation des tickets de support.

L'Architecture CGNAT (NAT444)

Pour dépasser les limites du NAT à niveau unique, les réseaux d'entreprise doivent adopter une architecture NAT de niveau opérateur (Carrier-Grade NAT), spécifiquement le modèle NAT444. Le nom fait référence aux trois couches d'espace d'adressage IPv4 impliquées dans la chaîne de traduction.

Niveau 1 — Couche CPE / Point d'Accès : Les appareils des abonnés se voient attribuer des adresses IP privées de l'espace RFC 1918 (par exemple, 192.168.x.x). Le point d'accès ou l'équipement d'abonné (CPE) effectue la première traduction NAT.

Niveau 2 — Passerelle CGNAT : Le CPE traduit les adresses privées RFC 1918 vers l'espace d'adressage partagé RFC 6598 (100.64.0.0/10). Cet espace intermédiaire est spécifiquement réservé à l'utilisation entre l'infrastructure du fournisseur de services et la passerelle CGNAT. L'utilisation de RFC 6598 — plutôt qu'une autre plage RFC 1918 — empêche le chevauchement d'adresses et les conflits de routage dans les environnements multi-locataires complexes.

Niveau 3 — Internet Public : La passerelle CGNAT effectue la traduction finale des adresses RFC 6598 vers une adresse IPv4 publique partagée. C'est l'adresse visible par les services externes.

Allocation de Blocs de Ports : La Décision de Conception Critique

Le choix de configuration le plus important dans un déploiement CGNAT est la stratégie d'allocation de ports. Deux approches existent :

Allocation Dynamique de Ports (DPA) : Les ports sont attribués par session à partir d'un pool partagé. Cela maximise l'efficacité d'utilisation des ports mais génère une entrée de journal pour chaque établissement et chaque fin de session — créant une charge de conformité et d'infrastructure à grande échelle.

Allocation de Blocs de Ports (PBA) : Un bloc contigu de ports est attribué à chaque abonné lors de l'initiation de sa première session. Le bloc reste alloué jusqu'à l'expiration de la session de l'abonné. Cette approche ne génère des journaux qu'au moment de l'attribution et de la libération du bloc, réduisant le volume de journaux jusqu'à 98 %.

Configuration Parameter	Recommended Value	Rationale
Ports par abonné (taille du bloc PBA)	500	Suffisant pour une utilisation multi-applications moderne sans épuisement du pool
Max d'abonnés par IP publique	128	Maintient plus de 500 ports par utilisateur avec 64 000 ports utilisables par IP
Max de sessions concurrentes par abonné	2 000	Empêche un seul appareil compromis d'épuiser le bloc
Délai d'expiration de session (TCP établi)	7 440 secondes (RFC 5382)	S'aligne sur les recommandations de l'IETF pour le comportement NAT
Délai d'expiration de session (UDP)	300 seconds	Empêche les mappages UDP obsolètes de consommer de l'espace de port

Référence sectorielle : NFWare, un fournisseur CGNAT spécialisé avec des déploiements auprès de plus de 100 FAI, recommande un maximum de 128 abonnés par IP publique avec 500 ports alloués par abonné. Dépasser ce seuil — par exemple, passer à 256 abonnés par IP avec 250 ports chacun — augmente considérablement le risque de coupures de session lors des pics de charge.

IPv6 Dual-Stack comme voie de migration à long terme

CGNAT est une stratégie d'atténuation, pas une solution permanente. La trajectoire architecturale correcte est un déploiement Dual-Stack : exécuter IPv6 nativement aux côtés d'IPv4 avec CGNAT. Les appareils modernes et les principaux CDNs (Google, Netflix, Meta, Cloudflare) préfèrent fortement IPv6 lorsqu'il est disponible. Dans un environnement Dual-Stack bien configuré, 60 à 70 % du trafic total peut être déchargé vers IPv6, réduisant considérablement la charge sur le pool CGNAT IPv4 et prolongeant sa durée de vie effective.

Pour les environnements de santé et de transport où le support des appareils hérités est critique, le Dual-Stack offre également une voie de migration propre : les appareils compatibles IPv6 effectuent une transition native, tandis que les appareils hérités IPv4 uniquement continuent de fonctionner via CGNAT sans aucune perturbation pour l'utilisateur.

Guide d'implémentation

Étape 1 : Auditez votre allocation IP actuelle et la densité des appareils

Avant de déployer CGNAT, établissez une base de référence. Recueillez les données suivantes de votre système de gestion de réseau existant :

Nombre maximal d'appareils simultanés par sous-réseau
Sessions moyennes et maximales par appareil
Pourcentage d'utilisation actuelle de l'IP publique
Configurations de délai d'attente NAT existantes

Ces données informent directement le dimensionnement de votre bloc PBA et les exigences de votre pool d'IP publiques.

Étape 2 : Concevez le réseau intermédiaire RFC 6598

Allouez le bloc 100.64.0.0/10 pour le réseau intermédiaire de classe opérateur. Planifiez le sous-réseau pour qu'il corresponde à la topologie de votre campus — généralement un /24 ou /23 par bâtiment ou segment de couche d'accès. Assurez-vous que votre infrastructure de routage ne divulgue pas les préfixes RFC 6598 à l'internet public ou aux partenaires de peering.

Étape 3 : Déployez et configurez la passerelle CGNAT

La passerelle CGNAT est généralement un appareil matériel dédié ou une fonction réseau virtualisée (VNF) fonctionnant sur du matériel serveur standard. Paramètres de configuration clés :

Pool NAT : Attribuez votre bloc IPv4 public au pool NAT. Assurez-vous que le pool est dimensionné pour votre ratio cible d'abonnés par IP.
Configuration PBA : Définissez la taille du bloc à 500 ports. Configurez le nombre maximal de blocs par abonné à 1 (avec la possibilité d'étendre à 2 si un abonné épuise son bloc initial, plutôt que d'augmenter la taille du bloc de base).
Journalisation : Configurez la sortie syslog vers votre SIEM. Avec PBA, chaque entrée de journal enregistre : l'IP interne de l'abonné, l'IP publique attribuée, le début du bloc de ports attribué, la fin du bloc, l'horodatage de l'allocation et l'horodatage de la libération.
Limites de session : Appliquez un maximum de 2 000 sessions simultanées par abonné pour prévenir les abus.

Étape 4 : Intégrez-vous à la couche d'identité et d'authentification

Dans les environnements utilisant les plateformes Guest WiFi , l'authentification du Captive Portal doit avoir lieu au niveau ou avant la limite NAT de niveau 1. Cela garantit que le fournisseur d'identité peut mapper avec précision les adresses MAC et les identifiants utilisateur à des adresses IP internes spécifiques avant que le trafic ne soit agrégé dans le pool CGNAT. La plateforme de Purple gère cela au niveau du point d'accès, maintenant une liaison utilisateur-IP propre qui persiste tout au long de la chaîne de traduction NAT.

Pour les déploiements d'accès sans mot de passe — comme décrit dans Comment un wi fi assistant permet l'accès sans mot de passe en 2026 — le même principe s'applique : la liaison d'identité doit être établie en amont de la passerelle CGNAT pour garantir une attribution précise des sessions.

Étape 5 : Configurez IPv6 Dual-Stack

Activez IPv6 sur tous les points d'accès et distribuez un préfixe /64 par VLAN via DHCPv6 ou SLAAC. Annoncez les routes IPv6 via votre fournisseur en amont. Vérifiez que le trafic CDN majeur (Google, Netflix, YouTube) se résout en enregistrements AAAA et est acheminé via IPv6 avant de réduire la taille de votre pool NAT IPv4.

Bonnes pratiques

Implémentez le NAT déterministe lorsque cela est possible. Le NAT déterministe utilise un mappage algorithmique entre l'adresse IP interne de l'abonné et son IP publique et bloc de ports attribués. Étant donné que le mappage est mathématiquement calculable, il n'est pas nécessaire de maintenir ou de journaliser une table de session — le mappage peut être rétro-ingénierie à la demande à des fins d'interception légale. C'est la référence absolue pour les déploiements soucieux de la conformité.

Distribuez la charge de la passerelle CGNAT. Évitez de centraliser tout le trafic CGNAT via un seul appareil. Distribuez les passerelles sur le campus ou dans les bâtiments pour éviter un point de défaillance unique. Les passerelles distribuées atténuent également le risque de réputation IP : si une IP publique du pool est signalée par un CDN pour des modèles de trafic suspects (le problème CAPTCHA), seule une fraction des utilisateurs est affectée.

Surveillez la réputation IP de manière proactive. Abonnez-vous aux flux de réputation IP (par exemple, Spamhaus, SURBL) et surveillez les IP de votre pool NAT public. Maintenez un pool de réserve d'IP propres à faire pivoter si une adresse active est mise sur liste noire. Ceci est particulièrement important dans les résidences étudiantes, où un petit nombre d'utilisateurs peuvent se livrer à des activités qui déclenchent des signalements d'abus.

Appliquez des limites de session par abonné. Une limite stricte de 2 000 sessions simultanées par abonné empêche un seul appareil compromis — par exemple, un participant à une attaque d'amplification DDoS — d'épuiser l'intégralité du bloc de ports alloué à cette IP publique. Pour en savoir plus sur la surveillance des performances réseau, consultez notre guide sur Comment mesurer la force et la couverture du signal WiFi .

Alignez-vous sur IEEE 802.1X pour le contrôle d'accèsl. Le déploiement de l'authentification basée sur les ports IEEE 802.1X au niveau de la couche d'accès garantit que seuls les appareils authentifiés reçoivent des attributions d'adresses IP. Cela réduit le risque que des appareils non autorisés consomment des allocations de ports et fournit une piste d'audit claire à des fins d'interception légale.

Dépannage et atténuation des risques

Le fardeau de la journalisation et de la conformité

Au Royaume-Uni et en Europe, en vertu du GDPR et de l'Investigatory Powers Act 2016, les opérateurs de réseau doivent être en mesure de retracer une adresse IP publique et un numéro de port jusqu'à un utilisateur spécifique à un horodatage précis. Il s'agit d'une obligation légale non négociable.

Le risque : Avec le CGNAT dynamique, la journalisation de chaque établissement et fin de session génère des téraoctets de données syslog par jour. Un déploiement de 1 000 utilisateurs avec allocation dynamique peut produire 500 millions d'entrées de journal quotidiennement. Cela submerge l'infrastructure SIEM, augmente les coûts de stockage et rend les enquêtes forensiques impraticables.

L'atténuation : L'allocation de blocs de ports (PBA) réduit le volume de journalisation jusqu'à 98 %. Avec le PBA, vous n'enregistrez que les événements d'attribution et de libération de blocs — généralement deux entrées de journal par utilisateur et par session, plutôt que des centaines ou des milliers. Assurez-vous que votre SIEM conserve ces journaux pendant un minimum de 12 mois pour se conformer aux exigences de conservation des données du Royaume-Uni.

Le CAPTCHA et le problème de réputation IP

Lorsque 128 utilisateurs partagent une seule IP publique, le volume de trafic agrégé peut déclencher des limitations de débit ou des protections anti-bot sur les principaux sites web. Le reCAPTCHA de Google, la gestion des bots de Cloudflare et des systèmes similaires utilisent des heuristiques basées sur l'IP qui peuvent classer à tort une IP CGNAT partagée comme une source de bot.

L'atténuation : Répartissez votre pool CGNAT sur plusieurs IP publiques. Surveillez proactivement les scores de réputation. Envisagez de déployer DNS-over-HTTPS (DoH) ou DNS-over-TLS (DoT) pour prévenir les problèmes de réputation basés sur le DNS. Informez les utilisateurs que les invites CAPTCHA occasionnelles sont un comportement connu dans les environnements IP partagés.

Problèmes de compatibilité des applications

Certaines applications — notamment les protocoles peer-to-peer, certaines implémentations VoIP et les plateformes de jeu héritées — reposent sur des mappages de ports cohérents ou l'initiation de connexions entrantes. Celles-ci peuvent échouer sous double NAT.

L'atténuation : Pour la VoIP, assurez-vous que votre passerelle CGNAT prend en charge l'ALG (Application Layer Gateway) pour le SIP. Pour les jeux, envisagez de mettre en œuvre un proxy UPnP ou un VLAN de jeu dédié avec un pool NAT séparé et moins dense. Pour les environnements de vente au détail où les systèmes de point de vente nécessitent une connectivité entrante, placez ces appareils sur un VLAN séparé qui contourne entièrement la couche CGNAT.

Retour sur investissement et impact commercial

Économies sur les dépenses d'investissement

Le déploiement du CGNAT offre des économies immédiates et substantielles sur les dépenses d'investissement (CapEx). Au prix du marché de 50 $ par adresse IPv4, une université de 5 000 lits nécessitant un rapport appareil-IP de 1:1 devrait acheter environ 35 000 adresses IP — un coût de 1,75 million de dollars. En déployant le CGNAT avec un rapport de 128:1, le même déploiement nécessite moins de 300 IP publiques, réduisant le coût d'acquisition des IP à environ 15 000 $.

Même en tenant compte du coût du matériel de passerelle CGNAT ou des fonctions réseau virtualisées (généralement 20 000 $ à 80 000 $ pour un déploiement à l'échelle d'un campus), l'économie nette est substantielle.

Réduction des dépenses d'exploitation

Une connectivité stable réduit directement les frais généraux du service d'assistance. Les événements d'épuisement des ports — le principal mode de défaillance du PAT standard à grande échelle — génèrent un volume disproportionné de tickets de support. Un déploiement CGNAT bien configuré avec des limites de session appropriées et le PBA élimine ce mode de défaillance, réduisant le volume du service d'assistance lié au réseau d'environ 30 à 40 %.

Différenciation concurrentielle dans le logement étudiant

Sur le marché concurrentiel du logement étudiant, la qualité du réseau est un critère de sélection primordial pour les futurs locataires. Les opérateurs qui peuvent démontrer une connectivité cohérente et à haut débit — validée par des tableaux de bord WiFi Analytics affichant des métriques de disponibilité, de qualité de session et de densité d'appareils — peuvent exiger des loyers plus élevés et atteindre un taux d'occupation supérieur. Cette stabilité d'infrastructure est également la base du déploiement de services avancés basés sur la localisation, comme souligné dans Purple Launches Offline Maps Mode for Seamless, Secure Navigation to WiFi Hotspots .

Étude de cas 1 : Résidences universitaires de 800 lits

Une université britannique gérant des résidences universitaires de 800 lits rencontrait des problèmes de connectivité chroniques pendant les heures de pointe du soir. L'enquête a révélé que leur configuration PAT à niveau unique, utilisant un sous-réseau public /29 (6 IP utilisables), épuisait les ports disponibles chaque soir à 19h30. L'opérateur a déployé une solution CGNAT avec PBA (500 ports par abonné, 128 abonnés par IP), a mis à niveau vers un sous-réseau public /27 (30 IP utilisables) et a activé le dual-stack IPv6. Les métriques post-déploiement ont montré une réduction de 94 % des événements d'épuisement des ports, une réduction de 38 % des tickets de service d'assistance liés au réseau et une réduction de 65 % du volume de journaux CGNAT par rapport à un pilote d'allocation dynamique initial. Le taux de déchargement IPv6 a atteint 62 % dans les 60 jours suivant le déploiement.

Étude de cas 2 : Opérateur de logement étudiant construit à cet effet (PBSA) de 1 200 chambres

Un opérateur privé de PBSA gérant trois sites dans deux villes du Royaume-Uni devait standardiser son architecture réseau avant l'ouverture d'un quatrième site. Leur infrastructure existante utilisait un mélange de NAT à niveau unique et de segmentation VLAN ad hoc, sans stratégie de journalisation cohérente. Un déploiement CGNAT avec NAT déterministe a été mis en œuvre sur les trois sites, permettant un mappage abonné-à-IP mathématiquement calculable sans aucune surcharge de journalisation de session. Cette approche a satisfait l'équipe juridique de l'opérateur concernant la conformité à l'interception légale, a éliminé le coût de stockage SIEM pour les journaux de session et a fourni un modèle d'architecture cohérent pour le quatrième site. L'opérateur a également intégré la plateforme Guest WiFi de Purple pour l'authentification du captive portal, avec la liaison d'identité établie en amont de tla passerelle CGNAT pour garantir une attribution précise des utilisateurs dans les rapports d'analyse.

Définitions clés

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.

Exemples concrets

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.

Commentaire de l'examinateur : 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.

Commentaire de l'examinateur : 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.

Commentaire de l'examinateur : 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.

Questions d'entraînement

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.

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

Voir la réponse type

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.

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

Voir la réponse type

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.

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

Voir la réponse type

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.