Moins de 30 des environ 25 millions de serveurs de noms basés au Royaume-Uni disposaient d'adresses IPv6 lorsque le rapport du gouvernement britannique sur le déploiement d'IPv6 a été publié en 2010. Ce point de départ historique explique pourquoi tant de plans d'adressage, de procédures d'assistance et de registres d'actifs ont été conçus autour d'IPv4.
Gérer les adresses IP signifie désormais maintenir un parc où les équipements peuvent utiliser l'un ou l'autre protocole, parfois sans que les administrateurs ne s'en rendent compte. La bonne pratique réside dans un propriétaire responsable, une intention de routage documentée et un registre d'attribution traçable pour chaque adresse. Les routes redondantes ne posent pas de problème ; la propriété ambiguë et l'accessibilité non expliquée en posent.
Quand utiliser des adresses DHCP statiques ou réservées
En août 2026, 54,27 % des 5 340 321 hôtes explorés étaient en dual-stack, tandis que 45,73 % restaient exclusivement en IPv4, selon les mesures au Royaume-Uni de l'Internet Society. Il s'agit de mesures d'hôtes explorés et non d'un recensement des équipements d'entreprise, mais elles illustrent pourquoi un inventaire exclusivement IPv4 ne décrit plus tout ce qu'une équipe réseau peut rencontrer.
Un appareil peut communiquer via IPv6 alors que sa fiche de centre de services, son objet pare-feu et sa fiche d'incident ne contiennent encore que l'IPv4. Traitez le dual-stack comme un second jeu d'enregistrements, incluant l'historique des adresses, et non comme une simple capacité de routage.
Choisissez une méthode d'attribution par classe d'équipement avant de concevoir les sous-réseaux. Le DHCP attribue des adresses pour une durée limitée ; une réservation fournit à un équipement spécifique une adresse prévisible via ce même service. Le glossaire DHCP offre une référence utile pour expliquer cette distinction à des collègues en dehors du service réseau.
Méthodes d'attribution d'adresses et quand les utiliser
| Méthode | Utiliser pour | Stabilité | Risque principal |
|---|---|---|---|
| DHCP dynamique | Invités, prestataires, clients de passage | Généralement conservée grâce aux renouvellements ; réutilisable après expiration | La réutilisation masque l'ancien détenteur de l'adresse sans journaux |
| Réservation DHCP | Imprimantes, points d'accès, caméras, IoT | Adresse fixe toujours attribuée par le DHCP | Réservation obsolète après le départ de l'équipement |
| Configuration statique | Routeurs, pare-feux, DNS, gestion hors bande | Permanente jusqu'à modification manuelle | Adresse orpheline sans historique de propriétaire |
| SLAAC | Clients IPv6 ordinaires sur un /64 | Les adresses stables peuvent coexister avec des adresses de confidentialité rotatives | Hôte invisible si l'IPAM ne le voit jamais |
| DHCPv6 | Clients IPv6 pris en charge nécessitant des enregistrements d'attribution côté serveur | Bail avec enregistrement côté serveur | Dérive de périmètre si le DNS n'est pas mis à jour avec le bail |
Adapter les baux au comportement des équipements
Un bail ne force pas un changement d'adresse à chaque renouvellement. Les clients renouvellent généralement l'adresse qu'ils détiennent déjà - n'utilisez donc pas la rotation DHCP comme contrôle de sécurité.
Pour un établissement hypothétique, un bail invité de huit heures peut convenir aux visiteurs en journée, tandis qu'un LAN personnel peut démarrer avec des baux de un à sept jours. Il s'agit de points de départ de configuration et non de seuils de conformité. Comparez l'occupation des pools, le trafic de renouvellement et les habitudes de visite avant de les ajuster.
Utilisez des réservations pour les équipements qui nécessitent un adressage stable mais doivent pouvoir être révoqués de manière centralisée. Conservez les adresses configurées manuellement en dehors des pools dynamiques et enregistrez l'administrateur responsable de leur modification. La configuration statique s'impose naturellement pour les infrastructures qui doivent démarrer ou rester administrables sans DHCP.
Sous IPv6, SLAAC permet aux clients de générer des adresses à partir d'un préfixe annoncé. DHCPv6 peut fournir des enregistrements d'attribution lorsque les clients le prennent en charge, mais il ne remplace pas les annonces de routeur pour la découverte du routeur par défaut et n'identifie pas automatiquement une personne.
Règle d'attribution : Donnez à chaque classe d'équipement une méthode par défaut, puis documentez les exceptions avec un propriétaire et une justification.
Étiquetez chaque VLAN actuel avec la méthode choisie. Un VLAN à usage mixte peut nécessiter des classes documentées séparées, plutôt qu'une règle artificielle exigeant que chaque appareil se comporte de manière identique.
Comment dimensionner les sous-réseaux et réserver de l'espace pour la croissance
Dimensionnez pour les appareils pouvant se connecter simultanément, y compris les remplacements, les clients temporaires et l'infrastructure. Ne choisissez pas un préfixe simplement parce qu'un autre site l'a utilisé.
Tailles de préfixe par défaut par zone réseau
Ce sont des points de départ techniques. Validez la demande des hôtes, les réservations cloud et la prise en charge de la plateforme avant d'adopter une ligne.
| Zone | Plan IPv4 | Plan IPv6 | Note de planification |
|---|---|---|---|
| LAN personnel ou utilisateur | /23 ou /24 | /64 | Laissez le bloc suivant libre avant que le VLAN ne se remplisse |
| WiFi invité | /22 pour un site à forte affluence | /64 | Baux courts et aucune route vers le personnel ou les serveurs |
| Serveurs et infrastructure | /24 ou plus petit, principalement statique | /64 | Chaque hôte géré est nommé dans le DNS direct et inversé |
| Gestion et hors bande | /26 ou /27 | /64 | Non routé vers les invités ni directement exposé à internet |
| Liaison point à point | /31 | /127 | À utiliser uniquement si les deux points d'accès le prennent en charge |
| Agrégat de site | Un bloc résumable par site | Souvent un /48 par site | Annoncez le résumé, pas chaque VLAN |
| VPC ou VNet cloud | Espace RFC1918 sans chevauchement | Allocation IPv6 du fournisseur | Vérifiez le chevauchement avant chaque fusion ou interconnexion (peering) |
Utilisez un calculateur de sous-réseau pour vérifier les limites et la capacité au lieu de calculer de mémoire l'arithmétique des préfixes. Pour les réseaux LAN IPv4 ordinaires, distinguez le nombre total d'adresses des adresses d'hôtes attribuables ; les plateformes cloud peuvent réserver des adresses supplémentaires.
Pour IPv6, les directives d'adressage du NHS England spécifient des adresses de 128 bits et une taille de sous-réseau standard de 64 bits. Utilisez /64 pour les LAN normaux et les segments de sécurité, et non des sous-réseaux clients plus petits destinés à économiser l'espace d'adresses.
Construire la hiérarchie avant de la remplir
Attribuez à chaque site un bloc de résumé IPv4 aligné. Lorsque l'allocation le permet, attribuez-lui également un agrégat IPv6, puis découpez les préfixes VLAN à l'intérieur de ces limites.
Rservez un bloc de croissance adjacent et correctement aligné pour les réseaux d'utilisateurs. L'adjacence seule ne garantit pas que deux préfixes puissent devenir un préfixe plus grand ; vérifiez donc la limite binaire avant de promettre une extension sans contrainte.
Espace d'adressage privé n'est pas synonyme d'unicité mondiale. Les bureaux, les entreprises acquises et les projets cloud peuvent choisir indépendamment des plages qui se chevauchent, puis découvrir le conflit lorsque quelqu'un demande un appairage.
Un schéma mono-site peut rester lisible sans lister les adresses individuelles :
| Rôle du VLAN | Préfixe attribué | Bloc parent | Réservation pour croissance |
|---|---|---|---|
| Personnel | /24 | Récapitulatif IPv4 du site | /24 aligné adjacent |
| Visiteurs | /22 | Récapitulatif IPv4 du site | /22 aligné séparé |
| Gestion | /27 | Récapitulatif IPv4 du site | /27 aligné adjacent |
| Segments clients IPv6 | /64 chacun | Agrégat IPv6 du site | Préfixes de segment non attribués |
Un résumé est une commodité de routage, pas une autorisation permettant à chaque zone de communiquer. Conservez des limites explicites pour les politiques relatives aux invités, à la gestion et aux serveurs.
Comment créer un inventaire d'adresses sous contrôle de version
Un inventaire d'adresses n'est utile que s'il reflète à la fois les attributions planifiées et la configuration active. La gestion des adresses IP (IPAM) enregistre le propriétaire de chaque préfixe, ce qu'il prend en charge et l'endroit où apparaissent ses informations d'adresse. Conservez un propriétaire, une route prévue et un enregistrement traçable pour chaque adresse.
Consignez le préfixe, le propriétaire, l'objectif commercial, le site, la zone de sécurité, la méthode d'attribution et la date de révision. Incluez les dates d'expiration pour les allocations temporaires, ainsi que les références de registre et de routage pour les blocs publics. Gérez l'inventaire en contrôle de version afin que chaque modification bénéficie d'une approbation et d'un diff explicite.
Rapprocher la configuration selon un ordre répétable
- Enregistrements de registre. Confirmez les allocations publiques que l'organisation est autorisée à utiliser.
- Zones DNS. Exportez les enregistrements directs et inverses, y compris les entrées A et AAAA obsolètes.
- Enregistrements DHCP. Collectez les baux, les réservations, les exclusions et les attributions DHCPv6.
- Objets de pare-feu et NAT. Consignez les adresses traduites, les services publiés et les règles de gestion.
- Réseaux cloud. Exportez les allocations de VPC, VNet et sous-réseaux sur l'ensemble des comptes ou abonnements concernés.
- État du routage. Comparez les annonces configurées avec les routes apprises et installées.
L'exportation la plus récente n'est pas automatiquement autoritaire. Un sous-réseau cloud non documenté peut être légitime ; un ancien objet pare-feu peut exposer un service sans propriétaire actuel. Attribuez chaque divergence à une personne capable d'en déterminer la raison d'être.
Utilisez des états de cycle de vie clairs tels que attribué, réservé, actif, obsolète et exposé à l'externe. Traitez l'exposition comme un indicateur distinct : un sous-réseau actif peut également être exposé à l'externe.
Vérifiez ce qui semble vide
Vérifiez chaque plage d'adresses détenue par l'organisation ou qu'elle est autorisée à évaluer, y compris les plages censées ne pas être utilisées. Cela permet de découvrir des allocations et des services oubliés sans étendre les vérifications au-delà des limites approuvées. Les recommandations de connectivité sécurisée du National Cyber Security Centre sur la ségrégation des réseaux OT concernent la séparation des réseaux de technologies opérationnelles ; elles n'incitent pas les organisations à analyser l'espace d'adresses public.
Vérifiez les enregistrements par rapport aux sources déjà incluses dans votre périmètre autorisé, telles que les zones DNS, les configurations réseau cloud, les enregistrements de routage et les informations de voisinage. Pour les équipements sensibles ou issus des technologies opérationnelles, suivez les procédures d'évaluation approuvées par l'organisation.
Documentez le périmètre représenté par chaque VLAN, y compris ses préfixes et ses voies autorisées. Pour les environnements du secteur public du Royaume-Uni, vérifiez si les services restreints tels que le PSN sont compatibles avec la configuration d'adressage prévue.
Conservez les procédures aux côtés de l'inventaire. Un logiciel de documentation technique peut aider à organiser les procédures d'exportation, de rapprochement et de gestion des exceptions, tandis que l'IPAM demeure l'autorité référente pour la propriété des adresses.
Un sous-réseau sans propriétaire constitue un risque opérationnel non résolu.
Automatisez les vérifications des chevauchements proposés, des propriétaires manquants et des enregistrements DNS ou de politique incohérents. Signalez la dérive en direct pour examen plutôt que de supprimer automatiquement une route de production inattendue.
Chaque adresse doit avoir un propriétaire responsable, un itinéraire prévu et un registre de modifications traçable. Conservez les identifiants et l'historique des baux identifiables hors des répertoires documentaires largement accessibles.
Comment attribuer et retirer une adresse
Utilisez le même processus de modification pour un serveur, l'extension d'un réseau invités ou un sous-réseau cloud. La mise en œuvre diffère, mais les exigences d'approbation, de preuve et de retrait ne doivent pas disparaître sous prétexte qu'un déploiement est automatisé.
Suivre le cycle de vie de l'attribution
- Soumettre la demande. Indiquez le propriétaire, l'objectif, le site, le protocole et la durée de vie requise. Identifiez toute connectivité entrante ou dépendance envers un fournisseur.
- Vérifiez l'inventaire pour éviter les chevauchements et contrôlez la capacité dans le résumé du site. Confirmez la méthode d'attribution pour la classe d'appareils.
- Réserver avant de configurer. Enregistrez le préfixe, la date d'expiration ou de révision, et la référence de modification afin que les demandes parallèles ne puissent pas la revendiquer.
- Créez ou étendez la plage DHCP, la réservation ou l'enregistrement statique. Pour les segments à double pile (dual-stack), configurez l'accord DHCPv6 ou SLAAC approuvé.
- Publiez le DNS direct et inversé le cas échéant. Ne libérez les enregistrements AAAA qu'une fois que le service a passé les tests IPv6.
- Mettez à jour le pare-feu, le NAT et les objets de routage à partir de l'allocation approuvée. Vérifiez la source, la destination et le chemin de retour prévus.
- Appliquez la politique d'accès client via l'annuaire et le contrôleur WiFi. Associez le personnel et les invités à leurs VLANs autorisés au lieu de vous appuyer sur un mot de passe partagé.
- Capturer des preuves. Confirmez le bail ou l'entrée voisine, la réponse DNS et un événement d'allocation pouvant être corrélé avec un utilisateur, un appareil ou un ticket.
- À l'expiration, supprimez l'allocation et les objets dépendants, puis marquez le préfixe comme obsolète. Vérifiez que le trafic résiduel et les dépendances ont cessé avant de le réintégrer dans le pool.
Le schéma de cycle de vie résume les contrôles de changement sans remplacer la liste de contrôle détaillée.
Si l'adresse doit envoyer des e-mails, effectuez des vérifications de réputation avant l'activation. Le test de liste noire d'e-mails de MailGenius permet d'identifier les adresses d'expédition répertoriées, bien qu'un résultat vierge ne garantisse pas la délivrabilité ni ne remplace une authentification de courrier appropriée.
Rendre l'événement d'attribution responsable
Une adresse seule ne permet pas d'identifier son détenteur après réutilisation. Conservez le début et la fin de l'attribution, le protocole, l'identifiant de l'appareil et la référence d'authentification correspondante, en utilisant une source horaire commune pour DHCP, RADIUS, les contrôleurs et DNS.
Les anciens UK Data Retention (EC Directive) Regulations 2009 obligeaient les fournisseurs de communications publiques à conserver certaines données de communication pendant 12 mois, y compris les informations d'attribution d'abonnés associées à un horodatage. Ce cadre a été remplacé et modifié depuis ; il ne s'agit pas d'une règle de conservation globale s'appliquant actuellement aux réseaux d'entreprise.
Définissez la durée de conservation en fonction des obligations applicables et des besoins de l'entreprise. Restreignez l'accès, protégez l'intégrité et vérifiez si un enquêteur autorisé peut reconstituer une attribution sans exposer les enregistrements d'utilisateurs non concernés.
Pour les connexions traduites, conservez les détails de mappage nécessaires à l'attribution, y compris les ports lorsque les adresses sont partagées. Un événement d'attribution unique constitue le point de départ, et non un substitut aux preuves d'authentification et de traduction.
Choisir entre conserver, louer, traduire ou réadresser
Commencez par les services IPv4 que vous ne pouvez pas supprimer : connexions partenaires, listes d'autorisations fournisseurs, points de terminaison VPN et applications héritées. Ces dépendances établissent l'empreinte publique minimale et stable dont votre parc a besoin.
Choisissez une option par environnement, et non une solution unique pour toute l'organisation. Un réseau invités et un service accessible aux fournisseurs présentent des exigences différentes en matière d'accès entrant, d'attribution et de continuité.
Options de conservation, de location, de traduction et de réadressage IPv4
| Option | Cas d'utilisation | Risque principal |
|---|---|---|
| Conserver les IPv4 possédées | L'espace public existant couvre les partenaires, les fournisseurs et les services hérités | Les blocs inutilisés restent masqués s'ils ne sont pas analysés et enregistrés |
| Louer un espace IPv4 | La croissance est réelle et le bloc peut être enregistré avec son propriétaire et sa route | Les plages louées s'écartent des registres et des enregistrements de routage |
| Carrier-grade NAT | Les clients ont uniquement besoin d'un accès sortant et l'imputation peut toujours être consignée | Les adresses partagées compliquent la journalisation par utilisateur et les services entrants |
| Dual-stack IPv6 | Les services et les clients sont compatibles IPv6 avec des contrôles correspondants | Enregistrements d'adresses supplémentaires et risque de contournement si les contrôles accusent du retard |
| Renumérotation | Les récapitulatifs ne se forment pas ou une plage RFC1918 entre en collision avec un VPC | Risque d'interruption et adresses codées en dur dans les applications |
Choisir par dépendance, pas par commodité
Conserver l'espace détenu est logique lorsque vous pouvez justifier son utilisation et maintenir son autorité de routage. N'en achetez pas et n'en louez pas davantage simplement parce que les administrateurs n'ont pas réconcilié les allocations inutilisées.
Pour les blocs loués, documentez le bailleur, l'utilisation autorisée, les accords de routage, les conditions de renouvellement et le processus de retrait. Anticipez la modification des listes d'autorisations fournisseurs et des points de terminaison publiés en externe si le bail prend fin. Un bloc en apparence disponible n'est pas déployable tant que la partie habilitée n'a pas autorisé son annonce.
Le NAT de niveau opérateur (CGNAT) convient à certains groupes de clients sortants, mais il introduit un comportement d'adresse partagée. Vérifiez la compatibilité des applications, la capacité des ports et la capacité à corréler les sessions traduites avant de l'utiliser comme mesure d'économie.
Le renumérotage constitue généralement la solution à long terme la plus propre pour les réseaux privés chevauchants. Si la plage de gestion d'un hôtel acquis entre en collision avec un VPC cloud, la traduction d'adresses peut rétablir temporairement un chemin de service restreint, mais elle ne produira pas de résumé de site cohérent et ne supprimera pas les adresses intégrées dans les applications.
Test de décision : Choisissez l'option que vous pouvez exploiter, attribuer et retirer en toute sécurité, et pas seulement celle que vous pouvez configurer le plus rapidement.
Utilisez le dual-stack pour les nouveaux environnements qui réussissent les contrôles de compatibilité et d'exploitation. Conservez les parcours fournisseurs restreints sur IPv4 jusqu'à ce que leurs exigences évoluent.
Consignez la décision pour chaque bloc, y compris la dépendance qui la justifie et la condition qui permettrait son retrait. Cela fournit à l'administrateur suivant une raison de maintenir l'attribution, ou la preuve qu'il est temps de la supprimer.
Déployer le dual-stack sans contournement IPv6
À l'échelle mondiale, environ 33 millions d'adresses IPv4 ont été transférées au sein des systèmes de registres régionaux au cours de l'année 2025, d'après le rapport d'adressage de Geoff Huston. Cette activité de transfert continue rappelle utilement que le déploiement d'IPv6 ne supprime pas immédiatement la dépendance commerciale et opérationnelle envers IPv4.
Exécutez l'IPv6 sous la forme d'un programme contrôlé. Répertoriez d'abord les applications et les dépendances, en recherchant les littéraux IPv4 intégrés, les ACL spécifiques aux protocoles, les hypothèses de surveillance et les fournisseurs qui nécessitent un point de terminaison IPv4 fixe.
Contrôler chaque étape d'extension
Pilotez un segment à faible risque avec une procédure de retour en arrière définie. Testez les transactions orientées utilisateur, et pas seulement les pings réussis, puis vérifiez le basculement, les contrôles d'identité et la visibilité des incidents avant d'étendre le déploiement.
- Contrôler la publication. Conservez les enregistrements AAAA jusqu'à ce que les tests applicatifs, la politique de pare-feu et la journalisation soient approuvés. Incluez les chemins externes, pas seulement l'accès interne.
- Protégez les annonces de routeur avec des contrôles de commutateur appropriés, tels que RA Guard lorsque cela est pris en charge. Transposez la politique de sécurité IPv4 prévue en règles IPv6, en incluant l'ICMPv6 nécessaire plutôt que de le bloquer de manière indifférenciée.
- Normaliser les adresses dans le SIEM. Les formes textuelles équivalentes doivent être corrélées de façon cohérente. La normalisation seule ne reliera pas les adresses de confidentialité rotatives, conservez donc également le contexte de l'équipement et de l'identité.
- Consignez le choix de SLAAC ou DHCPv6 pour chaque VLAN. Lorsque les deux fonctionnent intentionnellement, documentez leurs rôles et la manière dont la détection couvre les deux.
- Fournissez au support technique un script qui associe une adresse à son équipement, sa période d'attribution, son préfixe et la politique appliquée. Incluez des tests séparés pour chaque protocole afin qu'un basculement ne masque pas un chemin défaillant.
Mesurer l'état de préparation et les dépendances séparément
Suivez la préparation technique par rapport aux actifs et services inclus dans le périmètre du déploiement. Suivez la dépendance IPv4 dans un registre séparé, avec un propriétaire et une condition de suppression pour chaque service restant.
- Couverture de détection. Chaque actif compatible IPv6 du périmètre dispose d'un enregistrement détectable et d'un propriétaire responsable.
- Cohérence des routes et du DNS. Les préfixes annoncés et les enregistrements publiés correspondent à la configuration approuvée, les écarts étant résolus.
- Couverture de la politique. Chaque contrôle requis dispose d'une mise en œuvre IPv6 et d'un résultat de test enregistré.
- Exceptions d'exposition. Aucun service IPv6 accessible de l'extérieur ne reste non expliqué ou non approuvé.
- Réduction des dépendances. Le registre indique quels services n'ont plus besoin d'IPv4, sur la base de tests de transaction et de basculement.
Ne criez pas victoire simplement parce que les clients privilégient IPv6. Déclarez un segment prêt lorsque les administrateurs peuvent l'exploiter, résoudre ses dysfonctionnements et contenir un incident sans devoir recourir à des procédures exclusivement IPv4.
Ne retirez l'IPv4 qu'après que les propriétaires de services ont confirmé que le fonctionnement normal, la récupération et les connexions des fournisseurs n'en dépendent plus. Conservez les preuves de rétrogradation jusqu'à ce que ce retrait ait été testé.
Faire d'un seul système le propriétaire de chaque adresse
Choisissez un système de référence avant d'ajouter une autre feuille de calcul. Il doit contenir le préfixe approuvé, le propriétaire, la méthode d'attribution et les dates de cycle de vie, tandis que DHCP, DNS, les pare-feux et les comptes cloud fournissent la preuve de la mise en œuvre.
Le système n'est pas le propriétaire humain responsable. Désignez un responsable réseau qui maintient la politique d'attribution, et déléguez les responsabilités de sous-réseau aux personnes capables d'approuver les modifications et de résoudre les écarts.
Rapprocher un site avant d'y associer des rôles d'accès
Commencez par un site délimité plutôt que par une migration à l'échelle de l'ensemble du parc. Exportez ses étendues, ses réservations, ses hôtes statiques et ses plages cloud connectées, puis transformez les écarts en une file d'attente de travail contrôlée.
- Signaler les incertitudes. Identifiez les chevauchements, les attributions sans propriétaire et les objets dont personne ne peut expliquer l'utilité.
- Enquêter avant de renuméroter. Documentez ou retirez les plages sans propriétaire uniquement après avoir vérifié les dépendances et le trafic.
- Associer les rôles réseau. Associez les VLAN du site aux préfixes approuvés et distinguez les accès visiteurs, personnel, gestion et locataires.
- Tester les modifications d'identité. Confirmez que l'intégration, les changements de rôle et la révocation génèrent la politique d'accès prévue et des preuves d'audit exploitables.
Un compte d'annuaire identifie une personne ; un bail DHCP identifie une attribution. Liez ces enregistrements via des événements d'authentification et de contrôleur plutôt que de supposer qu'une adresse appartient de façon permanente à un employé.
Conserver la couche d'identité sans fil distincte
Lorsque l'accès sans fil nécessite cette couche d'identité, nous exécutons Purple en tant que superpostition cloud sur les points d'accès déjà détenus par l'établissement, évitant ainsi tout remplacement d'infrastructure. Notre plateforme fournit le WiFi invité, la sécurité 802.1X du personnel et les réseaux privés xPSK, avec un RADIUS-as-a-Service cloud remplaçant FreeRADIUS ou Windows NPS afin d'éliminer les serveurs d'authentification sur site à corriger ou à faire basculer.
La compatibilité dépend de la prise en charge du RADIUS, du changement d'autorisation et du jardin captif par le contrôleur. Il s'agit de la brique d'identité sans fil, et non d'un remplacement pour l'IPAM, le contrôle du routage ou les registres de cycle de vie des adresses.
Séparez l'autorité d'attribution du service d'authentification, avec une limite d'intégration claire. Un rôle d'accès doit sélectionner un réseau approuvé, et non créer un sous-réseau non documenté.
Désignez le propriétaire du plan d'adressage et réconciliez le premier site avant d'y associer des rôles WiFi. Cela donne aux administrateurs une base solide pour étendre l'accès sans augmenter l'incertitude.
Purple fournit un accès basé sur l'identité pour les invités, le personnel et les réseaux privés sur les points d'accès existants, vous aidant à relier vos décisions d'accès sans fil à un plan réseau documenté. Visitez Purple pour discuter de la compatibilité de votre contrôleur et de la manière dont la couche d'identité sans fil s'intègre à votre processus de gestion des adresses.
