Category "Réseaux et Wi-Fi"

Illustration générée par IA — visuel conceptuel.

Dans un hôtel connecté, la cybersécurité ne se résume pas à “séparer des VLAN”. On doit surtout décider qui peut accéder à quoi, dans quelles conditions, et comment on maintient l’ensemble (multi-prestataires, télémaintenance, support éditeurs, interventions d’urgence) sans créer d’accès permanents difficiles à tracer.

L’approche ISA/IEC 62443, historiquement portée par les environnements d’automatisation et de contrôle, apporte un cadre très utile pour l’hôtellerie : modéliser le périmètre en “zones et conduits”, puis traduire ce modèle en livrables projet (cartographie, exigences, règles d’accès/maintenance, preuves de recette) utilisables par la maîtrise d’ouvrage, l’intégrateur et l’exploitant.

Objectif de ce guide : proposer une démarche applicable à un projet hôtelier (neuf ou rénovation), sans posture “certification”.

Pourquoi IEC 62443 est utile en hôtellerie (sans “projet de certification”)

La série ISA/IEC 62443 décrit une approche holistique pour définir et maintenir des systèmes d’automatisation/contrôle sécurisés, avec des exigences et des processus qui dépassent la seule technique réseau (gouvernance, exploitation, maintenance). Cette série est présentée comme un cadre transverse (“horizontal”) utilisable dans de nombreux environnements OT/IACS ; dans un hôtel, elle aide à structurer un périmètre de systèmes techniques exploités sur la durée (et souvent maintenus par plusieurs intervenants).

Dans un hôtel, cette grille de lecture aide à éviter deux écueils fréquents :

• La sécurité “par couches empilées” : un VPN ici, un VLAN là, quelques mots de passe changés… sans modèle d’ensemble ni responsabilités claires.
• La sécurité “non maintenable” : une segmentation trop théorique, qui se dégrade au premier incident ou à la première intervention urgente.

À retenir : vous pouvez très bien viser une démarche alignée avec 62443 (livrables et exigences inspirés de la méthode) sans que l’objectif du projet soit une “certification”.

Le cœur de la méthode : définir des zones (à protéger) et des conduits (à contrôler)

Étape préalable : définir le “système sous considération” (SUC)

Avant de dessiner des zones, on fixe le périmètre utile au projet. Dans un hôtel, ce périmètre comprend typiquement des systèmes OT / courants faibles tels que :

• GRMS (gestion technique de chambre) et ses interfaces,
• GTB/GTC (CVC, énergie, supervision technique),
• Vidéosurveillance (CCTV / VMS),
• Contrôle d’accès (portes, locaux techniques, parkings),
• et, selon les sites, des briques “techniques” plus spécifiques (production, locaux machine, etc.).

Ce qui est hors périmètre (par exemple, le Wi‑Fi invité ou l’IT bureautique) reste important : il faut lister les interfaces entre OT et IT, car elles deviennent des conduits à sécuriser.

Zone : regrouper des actifs qui “se protègent de la même façon”

Une zone n’est pas un VLAN. C’est un regroupement d’actifs (équipements, serveurs, applications, postes opérateur, passerelles) qui partagent des exigences de sécurité proches, en fonction :

• des conséquences d’une compromission (sûreté, disponibilité, impact client, exploitation),
• de l’exposition (zones publiques, back-of-house, locaux techniques),
• des contraintes d’exploitation (fonctionnement continu, fenêtres de maintenance, tolérance au redémarrage),
• des acteurs (qui administre, qui maintient, qui supervise).

Conduit : formaliser et sécuriser les communications entre zones

Dans l’approche IEC 62443, un conduit sert à formaliser et contrôler les communications entre zones : quels flux existent réellement, pour quel besoin, via quels points de contrôle, avec quelles exigences (authentification, filtrage, journalisation, chiffrement si pertinent, etc.). IEC 62443‑3‑2 mobilise cette logique dans la démarche SUC → zones/conduits → risque → SL‑T → exigences. En pratique projet, un conduit devient un contrat d’échange : quels flux, pour quel besoin, via quels points de contrôle, avec quelles exigences (authentification, filtrage, journalisation, chiffrement si pertinent, etc.).

Conséquence importante : entre deux zones, vous pouvez avoir plusieurs conduits (par exemple, un conduit “supervision” et un conduit “maintenance”). Et un conduit peut se matérialiser par plusieurs mécanismes à la fois (pare-feu, bastion, DMZ, règles applicatives, procédure d’accès nominative…).

Traduire IEC 62443 en livrables projet (ceux qui “tiennent” en exploitation)

Le bénéfice principal de la démarche, c’est la production de documents relisibles, contractuels quand il le faut, et surtout réutilisables quand les prestataires changent.

Livrable : périmètre (SUC) et responsabilités

• Périmètre OT concerné (ce qui est “dans” et “hors” SUC).
• Liste des parties prenantes (hôtel / opérateur, IT, intégrateurs, mainteneurs, éditeurs).
• Responsabilités et circuits de validation (qui approuve une ouverture de flux ? qui crée un compte prestataire ? qui fait la revue des accès ?).

Livrable : cartographie “zones & conduits” (vue fonctionnelle + vue exploitable)

Deux niveaux sont utiles :

• Vue fonctionnelle (lisible MOA/exploitation) : zones, rôles, échanges “métier” entre zones.
• Vue exploitable (lisible intégration/réseau) : points d’entrée, équipements frontières, règles de filtrage attendues, chemins de télémaintenance, emplacements de journalisation.

Livrable : registre des conduits (le document qui évite les “exceptions” permanentes)

Pour chaque conduit, on documente au minimum :

• zones source/destination,
• finalité (supervision, événements, mises à jour, télémaintenance, etc.),
• points de contrôle (pare-feu, bastion, proxy, passerelle applicative),
• exigences (authentification, restrictions de flux, traçabilité),
• mode dégradé (que se passe-t-il si le conduit est indisponible ?).

Livrable : spécification d’exigences cybersécurité (orientée preuves, pas “liste d’outils”)

Au lieu d’imposer uniquement une architecture (“on met des VLAN”), on formalise des exigences vérifiables, par exemple :

• Accès et identités : comptes nominatifs, cycle de vie des comptes prestataires, règles d’accès d’urgence.
• Droits : séparation exploitation / maintenance, moindre privilège, rôles.
• Flux : logique de liste blanche, flux latéraux interdits par défaut, points d’entrée identifiés.
• Journalisation : quoi journaliser, où centraliser, qui relit, comment enquêter.
• Gestion des changements : procédure, validation, retour arrière, sauvegardes.
• Mises à jour et vulnérabilités : stratégie de patching adaptée aux contraintes OT (tests, fenêtres, exceptions documentées).

Livrable : gouvernance des accès et de la maintenance (souvent le vrai “risque OT” en hôtel)

En hôtellerie, le risque provient fréquemment de la multiplicité des intervenants (CCTV, contrôle d’accès, GTB, ascenseurs, TV, réseau…) et de l’héritage de comptes/mots de passe installateur. Ce livrable décrit :

• comment une intervention est demandée, validée et clôturée,
• comment les accès sont ouverts temporairement,
• comment les sessions sont tracées (et par qui elles sont consultables),
• comment on audite périodiquement les accès et les exceptions.

Sur la remise des documents et l’organisation côté exploitation, vous pouvez compléter avec : DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?

Exemple de découpage zones & conduits pour un hôtel (à valider en atelier)

L’exemple ci-dessous est une proposition de structuration (pas un modèle universel). Il doit être ajusté selon l’architecture réelle, les prestataires, et l’évaluation de risque.

Zones typiques (exemple)

• Zone supervision OT : serveurs et postes opérateur de supervision (GTB, GRMS, VMS, management contrôle d’accès), outils d’administration strictement OT.
• Zone terrain GRMS : contrôleurs de chambre, passerelles, équipements techniques de chambre dans le périmètre.
• Zone terrain GTB/GTC : contrôleurs techniques, automates, passerelles CVC/énergie.
• Zone sûreté – vidéosurveillance : caméras, enregistreurs, stockage, consoles opérateur dédiées.
• Zone sûreté – contrôle d’accès : contrôleurs, passerelles, postes de gestion, interfaces porte/parking.
• Zone OT DMZ / zone d’échange : services de transit entre OT et IT (bastion, relais de mises à jour, collecte de logs, interfaces applicatives).
• Zone IT (hors OT) : annuaire/IdP, ITSM, SIEM, PMS et services corporate, avec des interfaces OT cadrées.

Pour clarifier les échanges entre systèmes hôteliers (qui échange quoi, et pourquoi), voir aussi : PMS, GRMS, GTB, serrures et contrôle d’accès : qui échange quoi dans un hôtel ?

Conduits typiques (exemple)

• Conduit “supervision” : supervision OT ↔ terrain (GRMS/GTB), strictement limité aux flux nécessaires.
• Conduit “événements sûreté” : contrôle d’accès / VMS → supervision ou postes opérateur, avec exigences fortes de traçabilité.
• Conduit “OT ↔ IT” : exports contrôlés (tableaux de bord, événements, reporting), idéalement via une zone d’échange (DMZ OT).
• Conduit “télémaintenance prestataire” : accès distant vers OT, uniquement via un point de contrôle (bastion/DMZ), avec sessions traçables et accès temporaires.

Ce dernier conduit mérite presque un dossier à lui seul : en exploitation, c’est souvent lui qui “détricote” une segmentation pourtant correcte sur le papier.

Du niveau de sécurité cible à des exigences actionnables (sans sur-spécifier)

IEC 62443‑3‑2 formalise une démarche où l’on partitionne en zones et conduits, puis où l’on définit un niveau de sécurité cible (SL‑T) par zone et par conduit, avant de documenter les exigences de sécurité. L’intérêt, côté projet hôtelier, est de rendre explicite :

• les zones qui demandent une posture plus exigeante (ex. sûreté, accès aux chambres, supervision),
• les conduits “sensibles” (ex. OT↔IT, télémaintenance, administration),
• les compromis nécessaires avec l’exploitation (continuité de service, fenêtres d’intervention, contraintes legacy).

Pour éviter de transformer “SL‑T” en jargon, une méthode simple consiste à relier vos exigences à des familles d’objectifs. IEC 62443‑3‑3 décrit des foundational requirements (FR) qui couvrent notamment l’identification/authentification, le contrôle d’usage, l’intégrité système, la confidentialité des données, la restriction des flux, la réponse aux événements et la disponibilité des ressources.

Concrètement, au lieu d’écrire “SL‑T élevé”, on traduit en questions de conception et clauses projet :

• IAC / UC : comment sont gérés les comptes nominatif, prestataire, urgence ? Quelles preuves de revue d’accès ?
• RDF : quels flux doivent exister, et quels flux doivent être impossibles ?
• TRE : quels événements déclenchent une alerte, qui la reçoit, et quelle escalade ?
• RA : quelles protections ne doivent pas dégrader la disponibilité OT (scans, redémarrages, mises à jour forcées) ?

Ne pas confondre “VLAN” et “zones & conduits”

Un VLAN (ou une VRF, ou un sous-réseau) est une mise en œuvre possible de votre découpage, mais il ne couvre pas à lui seul :

• la gouvernance des accès (comptes, droits, prestataires, urgence),
• la télémaintenance (chemin unique, validation, traçabilité),
• la preuve (logs, horodatage, capacité d’enquête),
• la maintenabilité (ce qui change, qui peut changer, comment les exceptions sont gérées).

Pour une base claire côté réseau (segmentation et filtrage), vous pouvez compléter avec : VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ? et Architecture réseau IP d’un hôtel : comment faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS ?

Accès, télémaintenance et traçabilité : traiter explicitement le “conduit prestataire”

Principe de base : pas d’accès distant direct vers le terrain

Dans une logique “conduits”, on évite autant que possible les accès du type “PC prestataire → contrôleur terrain”. On préfère un chemin maîtrisé :

• un point d’entrée unique (bastion / passerelle d’administration) positionné dans une zone d’échange (DMZ OT),
• des comptes nominatifs et temporaires quand pertinent,
• une traçabilité des actions (au minimum, journalisation d’accès ; selon le contexte, enregistrement de session),
• une fermeture systématique de l’accès après intervention (pas de tunnels “toujours ouverts”).

Journalisation et horodatage cohérent

Le meilleur modèle zones/conduits perd beaucoup de valeur si l’on ne peut pas reconstituer une séquence d’événements. Une attention particulière doit être portée à la cohérence temporelle (équipements, serveurs, postes), car elle conditionne la qualité des logs et des preuves en cas d’incident.

Sur ce point, voir : Caméras et contrôle d’accès : pourquoi synchroniser l’heure des équipements ?

Recette : comment vérifier que la segmentation “tient” dans la durée

Une démarche alignée IEC 62443 devient réellement utile quand elle se traduit en tests de recette et en preuves (PV, exports de configuration, captures contrôlées, procédures). Exemples de vérifications pragmatiques à intégrer au projet :

• Tests de flux : depuis chaque zone, vérifier que seuls les flux attendus passent (et que les flux “interdits” échouent).
• Tests de télémaintenance : démontrer le chemin réel (entrée → bastion/DMZ → cibles), les droits, et la trace laissée.
• Tests de comptes : créer/supprimer un compte prestataire selon la procédure, puis prouver qu’il n’existe plus d’accès résiduel.
• Tests de mode dégradé : valider ce qui continue de fonctionner si un conduit OT↔IT est coupé.

Point d’attention OT : certaines pratiques IT “par défaut” (scan agressif, redémarrages automatiques, déploiement d’agents non maîtrisés) peuvent dégrader un environnement technique. La recette doit donc vérifier la sécurité et la continuité de service, avec des responsabilités claires.

Pour aller plus loin (et articuler avec vos livrables hôteliers)

• Cybersécurité d’un hôtel connecté : comment protéger GRMS, PMS, GTB et réseau ? (vue d’ensemble hôtel)
• VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ? (socle segmentation)
• Architecture réseau IP d’un hôtel (cohabitation des services IP)
• DOE et maintenance d’un hôtel connecté (remise, exploitation, gouvernance)
• Transformer NIST SP 800‑213 en exigences concrètes (complément utile côté exigences “device” et maintien en condition de sécurité)

Conclusion

Appliquer IEC 62443 dans un hôtel, ce n’est pas “faire de l’industriel” pour le principe. C’est surtout utiliser une méthode robuste pour structurer la sécurité OT en livrables de projet : un périmètre clair, une cartographie zones/conduits, des exigences vérifiables, et une gouvernance d’accès/maintenance adaptée au multi-prestataires.

Si vous ne deviez démarrer que par un seul chantier : formalisez la cartographie zones & conduits et traitez le conduit de télémaintenance (qui, quand, comment, via quel point de contrôle, et quelle trace). C’est souvent là que se joue la différence entre une segmentation “présentable” et une exploitation réellement maîtrisée.

Sources et documentation

• ISA — présentation de la série ISA/IEC 62443
• IEC SyC Smart Energy — synthèse IEC 62443 (zones & conduits, niveaux de sécurité)
• ANSI/ISA‑62443‑3‑2 — aperçu (preview) : zones, conduits, SL‑T
• ISA‑62443‑3‑3 — aperçu (preview) : foundational requirements
• IEC 62443‑2‑1:2024 — aperçu IEC (programme de sécurité asset owner)
• IEC 62443‑2‑4:2023 — fiche IEC (processus prestataires intégration/maintenance)
• IEC 62443‑4‑1:2018 — fiche IEC (cycle de développement sécurisé)

Illustration générée par IA — visuel conceptuel.

Pourquoi ce sujet apparaît maintenant dans les projets Wi‑Fi (hôtel, bureau, villa)

Dans un établissement recevant des invités (hôtel, espaces événementiels, bureaux avec visiteurs, grande villa), le DNS est souvent un « outil d’exploitation » : il aide à appliquer un filtrage simple, à faire apparaître un portail captif, et à produire des journaux utiles pour le support. Or, de plus en plus de systèmes et navigateurs savent utiliser DNS over HTTPS (DoH) : les requêtes DNS passent alors dans un flux HTTPS chiffré. Le résultat est très concret : les mécanismes qui reposent sur l’observation ou la modification du DNS « en clair » deviennent moins visibles, moins pilotables, parfois inopérants.

Important : l’objectif ici n’est pas de décrire des techniques de contournement, mais de donner un cadre de décision et des options « propres » pour garder une expérience Wi‑Fi prévisible, tout en conservant un niveau de maîtrise proportionné (sécurité, support, conformité interne).

Pour resituer le sujet dans l’exploitation d’un Wi‑Fi visiteurs, vous pouvez aussi lire : Wi‑Fi invités : sécurité, portail captif, isolation et expérience client.

DoH, en pratique : ce que dit le standard (et ce que cela implique)

Le RFC de référence décrit DoH comme un transport des messages DNS « au-dessus » de HTTPS (voir RFC 8484 — DNS Queries over HTTPS (DoH)). Dans ses considérations opérationnelles, il souligne un point directement pertinent pour les réseaux gérés : les mécanismes de filtrage ou d’inspection qui s’appuient sur du DNS non sécurisé ne s’appliquent pas de la même manière en environnement DoH, du fait des protections apportées par TLS.

Traduction projet : si votre stratégie repose sur « voir le DNS en port 53 » (ou injecter des réponses DNS), vous devez accepter que certains terminaux, dans certaines configurations, échappent à ce levier dès lors qu’ils utilisent DoH vers un résolveur externe.

Trois impacts typiques côté bâtiment : filtrage, portail captif, journaux

Filtrage “par DNS” : une promesse plus difficile à tenir sur un réseau invité

Dans beaucoup de projets, le filtrage côté Wi‑Fi invités est volontairement simple : listes de domaines, catégories, SafeSearch, anti‑malware “DNS‑based”. Tant que le terminal interroge votre résolveur (ou votre service de filtrage DNS), la politique est visible. Avec DoH vers un résolveur tiers, ce n’est plus garanti.

Conséquence : si le filtrage fait partie d’un engagement d’exploitation (par exemple « Wi‑Fi famille »), il faut cadrer ce que vous garantissez réellement sur du BYOD, et sur quels périmètres vous pouvez être strict (terminaux gérés vs invités).

Portail captif : attention aux portails qui reposent sur des détournements DNS/HTTP

De nombreux portails captifs historiques “fonctionnent” en pratique en jouant sur DNS et/ou HTTP : renvoyer une adresse identique pour toutes les requêtes DNS, ou intercepter les requêtes HTTP et renvoyer un redirect. Le document de conception Chromium OS sur la détection de portails décrit explicitement ces schémas comme fréquents dans les portails d’hôtels, cafés ou aéroports (voir Chromium OS — Network Portal Detection).

Le risque avec DoH n’est pas uniquement « le portail ne s’affiche pas » : c’est surtout une variabilité d’expérience selon les terminaux (navigateur, OS, applications), car certains parcours d’onboarding supposent implicitement un DNS “pilotable”. Le RFC 8952 — Captive Portal Architecture rappelle d’ailleurs une limite structurelle : les solutions de portail captif qui affectent DNS/HTTP fonctionnent généralement comme prévu avec les navigateurs, mais peuvent casser d’autres applications utilisant ces protocoles, et les applications d’autres protocoles ne sont pas forcément alertées que le réseau est captif.

En environnement hospitality, cela se traduit souvent par des symptômes “terrain” : applications qui semblent « sans Internet » alors que le Wi‑Fi est associé, casting qui ne se comporte pas comme attendu, ou parcours de connexion qui dépend trop d’un seul mécanisme.

Journalisation DNS : utile pour le support… mais moins complète si une partie du DNS part en DoH externe

Beaucoup d’organisations s’appuient sur les journaux DNS pour diagnostiquer : « l’utilisateur a-t-il bien résolu tel domaine ? », « y a-t-il eu des requêtes suspectes ? », « quel équipement a tenté quoi ? ». Si une partie des terminaux envoie du DNS en DoH vers un service tiers, votre résolveur local ne verra pas ces requêtes : la journalisation “DNS‑centrée” perd en exhaustivité.

Point de gouvernance : ce n’est pas “plus de logs”, c’est “pas les bons logs au même endroit”. Il faut donc décider où placer l’observabilité (réseau, proxy/SWG, EDR, SIEM…), et ce qui est réellement nécessaire pour l’exploitation (support, sécurité, audit interne).

Réponses « propres » : options de conception plutôt qu’un bras de fer avec le BYOD

1) Séparer clairement les périmètres : invités vs métiers vs technique

La réponse la plus robuste (et la plus “bâtiment”) consiste souvent à limiter ce que vous attendez du réseau invité, et à renforcer ce qui compte sur les périmètres que vous maîtrisez :

• Invités (BYOD) : viser une expérience simple, stable, et une isolation réseau forte ; accepter que vous ne contrôlez pas le terminal (et donc pas complètement son DNS).
• Staff / back‑office : politiques de sécurité plus strictes, supervision, contrôle des postes.
• IoT bâtiment / GRMS / GTB / CCTV : segmentation, flux minimaux autorisés, et dépendances documentées.

Cette logique rejoint l’architecture globale d’un réseau hospitality. Voir : Architecture réseau IP d’un hôtel : faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS, ainsi que Cybersécurité d’un hôtel connecté : comment protéger GRMS, PMS, GTB et réseau ?.

Si vous cherchez une explication plus “méthode” sur la séparation des usages, vous pouvez aussi lire : VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?.

2) Concevoir le portail captif comme un service (parcours, compatibilité, modes dégradés)

Le message du RFC 8952 est utile à traduire en cahier des charges : un portail captif n’est pas seulement une redirection, c’est un service d’onboarding qui doit tenir face à des applications et OS variés.

Recommandations de projet (sans entrer dans des recettes techniques) :

• Éviter de dépendre d’un “détournement DNS” pour déclencher l’expérience de connexion ; à défaut, en connaître les limites.
• Tester le parcours avec plusieurs profils de terminaux (smartphones, laptops, objets de chambre, usages de salles de réunion) et pas seulement “un navigateur sur un PC”.
• Prévoir un mode secours exploitable par l’accueil ou le support (information simple, procédure, escalade), car la variabilité des terminaux est une donnée de base de l’hospitality.

Pour la partie “dépendances invisibles” (DNS/DHCP/RADIUS) qui peut aussi se confondre avec des symptômes liés au DNS chiffré, voir : Wi‑Fi d’hôtel en panne : vérifier DNS, DHCP et RADIUS.

3) Sur les équipements que vous gérez : poser une politique endpoint explicite sur DoH

Sur le périmètre géré (postes staff, tablettes d’accueil, équipements de salles, flotte entreprise), le bon levier est souvent la politique endpoint (MDM/AD/gestion navigateur) plutôt qu’une bataille sur le réseau invité.

• Microsoft Edge documente la stratégie DnsOverHttpsMode (off/automatic/secure) et détaille les comportements associés : Microsoft Edge — Policy DnsOverHttpsMode.
• Apple (MDM) documente le payload com.apple.dnsSettings.managed (protocole HTTPS ou TLS, Server URL) pour pousser des réglages de DNS chiffré sur les appareils supervisés : Apple — DNS Settings payload (MDM) et Apple device-management (spécification du payload).

Objectif : être cohérent. Soit vous désactivez DoH sur un périmètre donné (si votre politique interne l’exige), soit vous l’accompagnez avec un DNS chiffré sous contrôle (voir point suivant).

4) Proposer un DNS chiffré “sous gouvernance” (plutôt que subir un DoH tiers)

Dans certains contextes, la réponse la plus propre n’est pas d’empêcher le DNS chiffré, mais de fournir un DNS chiffré opéré/maîtrisé par l’organisation (en interne ou via service managé), surtout pour les segments staff et techniques. Microsoft décrit l’activation et le dépannage dans sa documentation sur le DNS chiffré et DoH : Microsoft Learn — DNS Encryption using DNS over HTTPS et Enable DNS over HTTPS in DNS Server.

Intérêt projet : vous conciliez confidentialité sur le Wi‑Fi (DNS chiffré) et exigences d’exploitation (split‑DNS, politiques internes, journalisation adaptée), au lieu d’avoir des terminaux qui “sortent” vers des résolveurs publics hétérogènes.

5) Tirer parti des mécanismes de “signal réseau” quand ils existent… sans les surestimer

Firefox documente des mécanismes pour éviter d’activer DoH par défaut sur des réseaux où il peut casser des fonctions locales (noms privés, filtrage, etc.). Mozilla décrit notamment le principe du canary domain use-application-dns.net et précise ses conditions et limites : il ne s’applique pas si l’utilisateur active DoH manuellement. Voir : Mozilla — Configure networks to disable DNS over HTTPS et Mozilla — Canary domain use-application-dns.net.

C’est une piste utile de gouvernance (surtout en environnements corporate), mais elle reste dépendante du navigateur et de son mode d’activation : on la considère comme un signal, pas comme un contrôle universel du parc invité.

Mini plan de tests (exploitation) : valider l’impact sans “sur‑ingénierie”

Avant de décider “bloquer vs accompagner”, un plan de tests simple évite les décisions théoriques. Voici une grille orientée exploitation (à adapter à votre contexte et à vos fournisseurs) :

Ce que vous testez	Ce que vous observez	Limites à garder en tête
Onboarding portail captif (plusieurs OS/navigateurs)	Affichage de la page, stabilité de la session, réauthentification après veille	Un test « navigateur » ne couvre pas les apps non-navigateur ; le RFC 8952 souligne les limites des mécanismes DNS/HTTP pour ces cas.
Services sensibles côté client (casting, applis de réunion, streaming)	Découverte, connexion, comportement en “réseau captif”	Les symptômes peuvent être confondus avec des dépendances DNS/DHCP/RADIUS.
Filtrage annoncé sur Wi‑Fi invités	Écart entre filtrage “théorique” et filtrage réellement constaté	Avec DoH, les leviers DNS non chiffrés ne s’appliquent pas nécessairement (voir RFC 8484).
Observabilité (support)	Quels journaux sont vraiment exploitables lors d’un incident	La journalisation DNS n’est plus exhaustive si une partie du DNS part en DoH externe.

À retenir (décisionnel)

• DoH chiffre le DNS dans HTTPS ; le RFC 8484 explique pourquoi les approches de filtrage/inspection basées sur du DNS non sécurisé deviennent moins opérables en environnement DoH.
• Les portails captifs “historiques” basés sur DNS/HTTP sont structurellement fragiles (compatibilité applicative) ; un DNS chiffré peut accentuer la variabilité d’expérience côté invité (voir RFC 8952).
• La réponse la plus robuste est souvent : segmentation (invités vs interne), politiques endpoint sur le périmètre géré, et éventuellement un DNS chiffré sous gouvernance plutôt qu’un DoH tiers.

Sources et documentation

• RFC 8484 — DNS Queries over HTTPS (DoH)
• RFC 8952 — Captive Portal Architecture
• Chromium OS — Network Portal Detection (principes et comportements observés)
• Mozilla — Configure networks to disable DNS over HTTPS ; Mozilla — Canary domain use-application-dns.net
• Microsoft Learn — DNS Encryption using DNS over HTTPS ; Enable DNS over HTTPS in DNS Server
• Microsoft Edge — Policy DnsOverHttpsMode
• Apple — DNS Settings payload (MDM) ; Apple device-management (spécification du payload)

Si vous préparez une rénovation ou un nouveau site, l’étape la plus efficace est souvent de formaliser ces choix dans un livrable d’exploitation (périmètres, politiques, tests et modes dégradés), puis de valider sur une zone pilote avant généralisation. Pour cadrer ce livrable, vous pouvez compléter avec : DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?.

Illustration générée par IA — visuel conceptuel.

Un Wi‑Fi « entreprise » ou « staff » basé sur 802.1X est souvent perçu comme plus robuste qu’un simple mot de passe partagé. Pourtant, un incident revient régulièrement en exploitation : l’expiration d’un certificat qui entraîne une vague d’échecs d’authentification et, dans le pire cas, une indisponibilité quasi totale du service sur les terminaux concernés.

Ce guide propose une méthode vendor‑agnostic (sans pas‑à‑pas produit) pour prévenir ce type de panne en environnement commercial et hôtellerie au Maroc : inventaire des certificats, calendrier, renouvellement sans rupture, tests réalistes, gestion de la révocation et scénarios de mode dégradé.

Ce qui se passe réellement quand « le Wi‑Fi tombe » à cause d’un certificat

Dans un Wi‑Fi 802.1X en EAP‑TLS, l’accès réseau dépend d’un échange TLS encapsulé dans EAP. La décision d’accepter ou de refuser la connexion s’appuie notamment sur la validation de certificats X.509 : période de validité, chaîne de confiance et, selon les politiques, vérification du statut de révocation.

Une fois la date de fin de validité (notAfter) dépassée, la validation PKIX échoue : le certificat n’est plus considéré comme valide « au temps courant ». Cette logique est décrite dans la validation de certificats X.509 (RFC 5280), et elle s’applique aux échanges TLS utilisés par EAP‑TLS (RFC 5216 ; pour TLS 1.3 : RFC 9190).

Pourquoi l’impact peut être massif

• Certificat serveur EAP‑TLS expiré : beaucoup (voire la majorité) des terminaux refusent la connexion au SSID « staff »/« corporate ».
• Intermédiaire (CA) expiré : panne plus « surprenante » car le certificat serveur peut sembler encore valide, mais la chaîne ne l’est plus.
• Certificats clients expirés : impact ciblé sur certaines populations (terminaux métier, postes administratifs, équipements d’exploitation), parfois sans affecter le Wi‑Fi invité.
• Révocation / statut : selon l’architecture, la disponibilité d’OCSP/CRL et le comportement des clients peuvent créer des échecs intermittents ou différés. EAP‑TLS a une contrainte particulière : le terminal n’a pas forcément de connectivité IP avant l’authentification, donc la vérification « en ligne » n’est pas toujours possible pendant l’échange initial (RFC 5216).

Étape 1 — Faire l’inventaire des certificats « qui peuvent casser le Wi‑Fi »

Objectif : être capable de répondre à ces questions, avant l’incident :

• Quel certificat peut faire tomber quel SSID / quel profil Wi‑Fi ?
• Quelle population est impactée (staff, terminaux métier, IoT, BYOD, prestataires) ?
• Où se renouvelle ce certificat (PKI interne, prestataire, service managé) et qui est responsable ?
• Quelle dépendance existe (chaîne intermédiaire, racine, mécanisme de révocation) ?

Registre minimal recommandé

Sans imposer d’outil, un registre simple (tableur ou CMDB) suffit si vous le tenez réellement à jour :

• Certificat serveur EAP‑TLS (serveur RADIUS / service d’authentification) : identité présentée (CN/SAN), chaîne fournie, date d’expiration, emplacement, procédure de déploiement.
• Chaîne intermédiaire (sub‑CA) : dates d’expiration, où elle est stockée et comment elle est distribuée côté serveur.
• Racines de confiance effectivement présentes sur les terminaux (MDM, GPO, profils mobiles, images poste).
• Certificats clients (si EAP‑TLS mutualisé) : par population, mode d’enrôlement, règles de renouvellement, mécanisme de révocation.
• Statut / révocation : CRL, OCSP, OCSP stapling (notamment mis en avant côté TLS 1.3 dans EAP‑TLS : RFC 9190 ; OCSP : RFC 6960).

Conseil d’exploitation : relier certificats et dépendances « invisibles »

Dans beaucoup d’hôtels et de sites tertiaires, l’échec 802.1X se confond avec d’autres causes (DNS, DHCP, RADIUS indisponible, problème de routage, etc.). Une bonne pratique consiste à documenter le « chemin d’accès » complet. Pour une approche checklist des dépendances, vous pouvez compléter ce guide avec : Wi‑Fi d’hôtel en panne : vérifier les services d’adressage, de noms et d’authentification.

Étape 2 — Mettre un calendrier de renouvellement (et pas seulement une alerte)

Le piège classique est de découvrir l’expiration « trop tard » : on renouvelle dans l’urgence, on déploie sans tests, et on crée une panne différente (mauvaise chaîne, identité serveur inattendue, terminaux non provisionnés en confiance, etc.).

Deux horizons à formaliser

• Renouvellement standard : une fenêtre suffisamment en amont pour préparer le nouveau certificat, tester et orchestrer le déploiement (y compris la propagation MDM/GPO côté clients).
• Incident imminent : un runbook plus « opérationnel » (gel des changements non essentiels, communication interne, validation accélérée, décision de mode dégradé si nécessaire).

Le calendrier doit couvrir toute la chaîne (serveur + intermédiaires + racines si rotation), pas uniquement le certificat « visible » côté serveur.

Étape 3 — Renouveler sans rupture : principes agnostiques produit

Un renouvellement EAP‑TLS réussi consiste à changer un composant cryptographique sans casser la confiance des terminaux. Les étapes exactes dépendent de votre contrôleur Wi‑Fi, serveur RADIUS et outils poste, mais les principes restent constants.

Principe A : ne changez pas la « confiance » au même moment que le certificat serveur, sauf si c’est piloté

Si vous introduisez une nouvelle CA (racine/intermédiaire), la priorité est de distribuer cette confiance à tous les terminaux concernés avant la bascule du serveur. Les environnements hôteliers sont particulièrement exposés si des appareils sont rarement connectés au réseau interne (terminaux saisonniers, appareils de prestataires, stocks en réserve).

Principe B : vérifier ce que les clients « attendent » du serveur

Selon la configuration des supplicants, les clients peuvent vérifier l’identité du serveur (CN/SAN), l’usage du certificat (Extended Key Usage) et la chaîne. EAP‑TLS recommande de valider des points comme l’usage prévu du certificat via l’Extended Key Usage (voir RFC 5216).

Principe C : prévoir une coexistence maîtrisée

Dans un parc hétérogène, certains terminaux mettent plus de temps à recevoir les nouveaux paramètres de confiance (ou ont des stacks TLS plus strictes). Prévoir une période de coexistence (ancienne et nouvelle confiance) peut réduire le risque, mais doit rester contrôlée et documentée (sinon, vous accumulez de la dette de sécurité).

Étape 4 — Tests : « comme si ça expirait demain »

La meilleure prévention est de tester avant la date critique, avec un panel de terminaux représentatifs. Le but n’est pas de tester « le Wi‑Fi » au sens radio, mais le chemin d’authentification et ce qui l’entoure.

Table de tests recommandés (et leurs limites)

Test	Objectif	Limites / points d’attention
Connexion EAP‑TLS sur un panel de terminaux	Valider que l’authentification passe après changement (certificat/chaîne)	Un panel incomplet donne une fausse confiance : inclure terminaux métier, OS variés, profils MDM/GPO, appareils « anciens » encore en production
Validation de chaîne présentée par le serveur	Vérifier que le serveur fournit la chaîne attendue (hors racine)	EAP‑TLS recommande que le serveur fournisse la chaîne pour faciliter la validation côté client (RFC 5216)
Test « heure incorrecte » (client et serveur)	Éliminer un faux diagnostic : un certificat peut être refusé si l’heure système est erronée	Ne remplace pas la supervision NTP ; utile surtout en incident ou sur équipements souvent éteints
Test de révocation (selon votre politique)	Vérifier le comportement en cas de certificat révoqué et la disponibilité des mécanismes de statut	En EAP‑TLS, la vérification en ligne peut ne pas être possible avant d’avoir du réseau ; le RFC prévoit des vérifications après authentification (RFC 5216)

Supervision : distinguer « qualité Wi‑Fi » et « échecs d’authentification »

Pour que l’alerte soit actionnable, vos outils (contrôleur Wi‑Fi, RADIUS, SIEM, supervision) doivent permettre de séparer :

• les problèmes radio (couverture, interférences, saturation),
• les problèmes d’accès réseau (DHCP/DNS),
• les problèmes d’authentification 802.1X (EAP‑TLS, certificats, chaîne, statut).

Sur la conception globale d’un réseau Wi‑Fi professionnel (au‑delà du sujet certificats), voir : Réseau Wi‑Fi professionnel : comment bien le concevoir en entreprise ?.

Expiration vs révocation : deux scénarios, deux gestes d’exploitation

Un point important pour les équipes IT et exploitation : expiration et révocation ne se traitent pas comme le même événement.

• Expiration : événement attendu (cycle de vie normal). La prévention repose sur le calendrier et les tests.
• Révocation : événement de sécurité (perte d’un terminal, suspicion de compromission, retrait d’accès). Les exigences de vérification du statut sont discutées dans les RFC (révocation et mécanismes associés : RFC 5280 ; OCSP : RFC 6960 ; EAP‑TLS TLS 1.3 : RFC 9190).

Recommandation de projet : documenter « qui peut révoquer » et « comment on vérifie »

Sans entrer dans des détails dépendants d’éditeurs, un document interne simple évite la panique en cas d’incident :

• quels cas déclenchent une révocation (perte d’équipement, départ d’un prestataire, incident sécurité),
• qui décide et qui exécute (PKI, IT, RSSI, prestataire),
• comment les terminaux obtiennent l’information de statut (CRL/OCSP) et quelles dépendances réseau cela implique.

Mode dégradé : décider avant la crise (et assumer le compromis)

Quand l’authentification 802.1X échoue massivement, la tentation est forte de « contourner » (changer de méthode, baisser le niveau de sécurité, ouvrir un SSID). En environnement hôtelier et commercial, cela peut exposer des systèmes métiers.

Un mode dégradé doit donc être une décision de risque préparée :

• SSID de secours très restreint (quarantaine / VLAN limité) pour maintenir quelques fonctions vitales.
• Accès filaire temporaire pour des postes critiques (réception, back‑office) lorsque c’est possible.
• Procédure d’inscription d’urgence pour terminaux métier, encadrée et tracée.

En hôtellerie, ce sujet s’inscrit dans une vision plus large de l’architecture IP (Wi‑Fi, VoIP, IPTV, sûreté, GRMS). Pour une vue d’ensemble utile en conception, voir : Architecture réseau IP d’un hôtel : comment faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS ?.

Runbook « jour J » : quoi vérifier quand la panne est déjà visible

1. Confirmer l’horodatage (heure/zone) sur : serveur(s) d’authentification, contrôleur/gestion Wi‑Fi, quelques terminaux représentatifs.
2. Identifier le point commun des échecs : même SSID, même profil EAP, même population (par exemple appareils métiers).
3. Isoler le certificat suspect : certificat serveur EAP‑TLS, intermédiaire, certificats clients d’une population.
4. Contrôler la chaîne présentée et la date de fin de validité.
5. Si statut/révocation en cause : vérifier la disponibilité et l’accessibilité des mécanismes (CRL/OCSP) et tenir compte du fait que le contrôle peut intervenir après l’obtention de connectivité selon les implémentations et les recommandations EAP‑TLS (RFC 5216).
6. Appliquer la correction (renouvellement, re‑déploiement de chaîne, distribution de confiance) puis re‑tester le panel.
7. Communiquer : périmètre impacté, contournement temporaire, état d’avancement, conditions de retour à la normale.

Ce qu’il faut documenter pour que l’incident ne se reproduise pas

• Registre des certificats Wi‑Fi (propriétaire, usage, chaîne, dates, procédure, plan de repli).
• Calendrier récurrent + alertes exploitables (pas une simple notification « à la date d’expiration »).
• Procédure de renouvellement avec fenêtre de tests et critères de validation.
• Procédure de révocation (qui, quand, comment, dépendances réseau).
• Scénario de mode dégradé validé et assumé (technique + sécurité + exploitation).

Quand faire appel à Domocasa

Si vous exploitez un Wi‑Fi 802.1X en entreprise ou en hôtellerie et que vous souhaitez sécuriser la phase « jour 2 » (inventaire, procédures, tests, modes dégradés, supervision), Domocasa peut vous accompagner sur l’architecture et la maintenabilité de l’infrastructure. Voir : Réseau d’entreprise.

Sources et documentation

• RFC 5216 — EAP‑TLS.
• RFC 9190 — EAP‑TLS 1.3.
• RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
• RFC 6960 — Online Certificate Status Protocol (OCSP).

Illustration générée par IA — visuel conceptuel.

Pourquoi IPv6 devient un sujet « exploitation » dans un hôtel

Dans un environnement hôtelier, IPv6 n’est pas un simple sujet « réseau ». C’est un choix d’architecture qui touche directement :

• l’expérience client sur le Wi‑Fi invités (portail captif, accès simple, compatibilité BYOD),
• la continuité de service des systèmes IoT/OT bâtiment (GTB/GRMS, contrôle d’accès, CCTV, capteurs),
• les usages IPTV/OTT et les équipements hétérogènes (TV, décodeurs, apps),
• la sécurité (politique firewall et zones),
• les journaux et la traçabilité (support, incidents, corrélation),
• les méthodes de dépannage (outils, runbooks, supervision).

L’objectif de ce guide est volontairement opérationnel : comprendre les modèles de déploiement (dual‑stack vs IPv6‑only avec NAT64/DNS64), leurs risques concrets en hôtellerie, et une méthode de migration progressive sans « demi‑IPv6 » difficile à exploiter.

IPv6 en clair : ce qui change vraiment (sans cours de routage)

IPv6 est un protocole différent, avec son en‑tête et des en‑têtes d’extension

IPv6 définit un en‑tête de base et un mécanisme d’extension headers chaînables, identifiés via le champ Next Header. Ce modèle fait partie de la spécification IPv6. RFC 8200

Conséquence projet : il ne suffit pas de « cocher IPv6 ». Le comportement des équipements de sécurité (firewall, inspection, détection) et des politiques (filtrage, journalisation) doit être validé en IPv6, au même niveau de rigueur qu’en IPv4.

En dual‑stack, le terminal choisit IPv4 ou IPv6 (et peut basculer si l’un est dégradé)

Dans un réseau où IPv4 et IPv6 coexistent (dual‑stack), un même terminal peut tenter l’un ou l’autre pour atteindre une destination. Les algorithmes côté clients visent justement à réduire les délais visibles quand une famille est défaillante ou plus lente, en lançant des tentatives concurrentes. RFC 8305 (Happy Eyeballs v2)

Implication hôtelière : un IPv6 « parfois cassé » peut se traduire par des lenteurs intermittentes (temps d’attente, comportements incohérents d’apps), tout en étant difficile à diagnostiquer puisque le terminal finira parfois par retomber sur IPv4… après un délai.

Les modèles de déploiement possibles en hôtellerie

Modèle A — IPv4‑only (héritage)

Vous limitez l’exploitation à un seul protocole et vous restez dans des schémas connus. Mais vous repoussez le sujet, et vous risquez de devoir compenser par davantage de complexité « autour » (NAT, plans d’adressage contraints, extensions de VLAN, interconnexions multi‑sites).

Modèle B — Dual‑stack (IPv4 + IPv6)

Le réseau fournit IPv4 et IPv6 sur les segments où c’est raisonnable (Wi‑Fi invités, LAN, certains VLAN métiers/techniques), et vous rendez les services accessibles dans les deux familles lorsque c’est pertinent.

• Avantage : compatibilité maximale (BYOD, objets hétérogènes, TV/décodeurs), migration progressive.
• Point de vigilance : vous opérez « deux piles » (adressage, règles, supervision). Le risque classique n’est pas la complexité technique en soi, mais l’asymétrie d’hygiène : une politique solide en IPv4 et une politique incomplète en IPv6.

Modèle C — IPv6‑only sur certains segments, avec NAT64/DNS64

Le segment (souvent candidat : Wi‑Fi invités, parfois un périmètre IoT maîtrisé) fonctionne sans IPv4. L’accès vers des destinations IPv4 est assuré via une chaîne de traduction et de résolution :

• NAT64 : traduction stateful permettant à des clients IPv6‑only de joindre des serveurs IPv4 en unicast TCP, UDP ou ICMP. RFC 6146
• DNS64 : côté DNS, synthèse de réponses AAAA à partir de réponses A, afin d’orienter le client IPv6 vers le traducteur (en cohérence avec NAT64). RFC 6147

En complément, on rencontre souvent 464XLAT dans les architectures IPv6‑only : combinaison d’une traduction stateful dans le cœur (référencée comme NAT64) et d’une traduction stateless côté « edge/client », pour fournir une connectivité IPv4 limitée à travers un réseau IPv6‑only. RFC 6877

Point clé hôtellerie : l’IPv6‑only avec traduction peut très bien fonctionner… à condition que les usages reposent sur le DNS et que les applications/équipements ne dépendent pas d’IPv4 « en dur » (littéraux IPv4, comportements atypiques). En Wi‑Fi invités, cela se valide par des tests représentatifs, pas par hypothèse.

Impacts concrets en hôtel : ce qui change par domaine

Wi‑Fi invités : portail captif, « walled garden » et cohérence IPv4/IPv6

Le Wi‑Fi invités est le plus exposé : appareils inconnus, diversité d’OS, exigences d’accès simple, pression sur le support.

En dual‑stack, le risque typique est un portail captif et des règles « pensées en IPv4 ». Exemple de symptômes :

• le portail s’affiche mais certaines apps restent bloquées (car elles sortent en IPv6),
• le parcours pré‑auth / post‑auth n’est pas strictement équivalent entre IPv4 et IPv6,
• l’hôtel croit « isoler »… mais laisse un chemin IPv6 moins filtré.

En IPv6‑only + NAT64/DNS64, vous ajoutez des dépendances critiques :

• le DNS récursif fourni au client doit être DNS64 (si vous adoptez ce modèle),
• le chemin vers l’Internet IPv4 doit bien passer par NAT64,
• les exceptions (paiement, OTA, outils d’assistance, etc.) doivent être testées « comme en vrai » (périmètre applicatif + conditions réseau réalistes).

Note d’exploitation : dans ce contexte, « walled garden » désigne généralement la liste d’exceptions autorisées avant authentification (par exemple DNS, accès à un site de paiement ou à une page spécifique), et elle doit rester cohérente en IPv4 et IPv6.

Pour la partie expérience et sécurité Wi‑Fi (portail captif, isolation, choix WPA3/OWE/802.1X), vous pouvez compléter avec : Wi‑Fi invités : sécurité, portail captif, isolation et expérience client et Wi‑Fi invités : quelle sécurité choisir pour garder une connexion simple ?.

IoT/OT bâtiment : stabilité, hétérogénéité, et risques « silencieux »

Dans un hôtel, les réseaux techniques et IoT/OT sont rarement homogènes. On y trouve des équipements à cycles de vie longs, des passerelles, des firmwares peu mis à jour, et des dépendances de prestataires.

• Dual‑stack est souvent le point de départ le plus prudent : vous conservez l’IPv4 pour le legacy et vous introduisez l’IPv6 là où vous maîtrisez (serveurs, supervision, passerelles, périmètres pilotes).
• IPv6‑only avec NAT64/DNS64 peut être pertinent sur un sous‑ensemble très maîtrisé (par exemple des équipements gérés, standardisés, et testés), mais il faut anticiper les cas où l’équipement contacte des services via IPv4 littéral ou via des protocoles peu tolérants à la traduction.

Sur la segmentation et la cohabitation des lots (Wi‑Fi, IPTV, VoIP, CCTV, GRMS), une lecture utile : Architecture réseau IP d’un hôtel : comment faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS ?

IPTV/OTT : diversité des terminaux et validation « références réelles »

Les services OTT reposent en général sur DNS et HTTPS, souvent via CDN. Dans ce contexte, IPv6 peut fonctionner sans douleur… mais l’écosystème hôtelier est hétérogène (TV de plusieurs générations, décodeurs, apps, DRM, mises à jour inégales).

Recommandation projet : quel que soit le modèle (dual‑stack ou IPv6‑only), validez sur vos références réelles (modèles de TV/décodeurs, apps effectivement déployées, scénarios d’usage client), avec une phase d’observation suffisante pour capter les effets « intermittents ».

Pour cadrer l’architecture TV côté hôtel : IPTV ou télédistribution coaxiale : quelle architecture pour un hôtel ?

VPN, support à distance et prestataires : éviter les angles morts

La bonne question n’est pas « le VPN supporte IPv6 » au sens marketing, mais :

• devez‑vous transporter des réseaux IPv6 dans le tunnel (accès admin, supervision, inter‑sites) ?
• vos politiques de filtrage et vos zones sont‑elles symétriques ?
• vos journaux et outils de sécurité conservent‑ils les adresses IPv6 (et les rendent‑ils exploitables) ?

Sur la gouvernance cybersécurité et la séparation des environnements dans un hôtel connecté : Cybersécurité d’un hôtel connecté : comment protéger GRMS, PMS, GTB et réseau ?

Firewall IPv6 : les points à traiter explicitement (pas « plus tard »)

Dual‑stack : « oublier IPv6 » équivaut à ouvrir une seconde porte

En dual‑stack, un même poste a potentiellement deux voies de sortie. Si votre politique est stricte en IPv4 mais permissive en IPv6 (par oubli, par défaut, ou par absence de règles), vous créez une voie de contournement involontaire.

Extension headers : valider le comportement de filtrage/inspection

IPv6 inclut un mécanisme d’en‑têtes d’extension chaînables. C’est un élément normal du protocole et il doit être compris par les briques de sécurité, au moins dans les cas couverts par votre périmètre. RFC 8200

À traduire en exigences projet : documenter et tester le comportement des équipements (firewall, IDS/IPS, outils de capture) sur les cas IPv6 pertinents pour votre exploitation, au lieu de supposer une équivalence automatique avec IPv4.

Politique simple par zones (exemple de logique)

Sans entrer dans une « norme » universelle, un hôtel gagne souvent à formaliser une politique par zones, puis à la décliner en IPv4 et IPv6 :

• Invités : flux sortants strictement nécessaires (avec journalisation), isolation inter‑clients, pas d’accès vers les réseaux techniques/métiers.
• IoT/OT : autoriser vers les collecteurs/contrôleurs et services attendus, bloquer le reste, limiter l’exposition latérale.
• Admin : accès restreint, comptes nominaux, bastion si applicable, supervision renforcée.

Journaux, traçabilité et exploitation : ce qui devient plus exigeant avec IPv6

« Qui était ce client ? » ne doit pas dépendre uniquement de l’adresse IP

En hôtel, les demandes support et les incidents imposent souvent de corréler un événement réseau à un contexte : terminal, utilisateur, chambre, période, SSID, etc.

Avec IPv6, la corrélation uniquement via l’adresse IP est fragile : selon les OS et les mécanismes de confidentialité (adresses temporaires), l’adresse source peut évoluer. RFC 8981 La bonne pratique consiste à préparer des points de corrélation complémentaires (selon votre modèle Wi‑Fi et vos outils) :

• identité (portail captif, comptes, jetons),
• logs contrôleur Wi‑Fi (association, session),
• logs d’authentification (si 802.1X/RADIUS),
• logs DNS (encore plus utiles en DNS64 : comprendre ce qui a été synthétisé, et quand),
• journaux firewall (avec une politique de conservation et d’export adaptée à l’exploitation).

Pour cadrer le sujet sous l’angle sécurité/exploitation (au‑delà des outils), une lecture normative utile : RFC 9099.

Sur les « services invisibles » qui font tomber un Wi‑Fi (et qui doivent être pensés avec le même sérieux en IPv6/dual‑stack) : Wi‑Fi d’hôtel en panne : vérifier les services d’adressage, de noms et d’authentification.

Adressage et nommage : éviter que le plan IPv6 devienne un second chaos

Dual‑stack signifie aussi « deux plans à tenir ». Même si IPv6 change les conventions, l’enjeu exploitation reste le même : une nomenclature cohérente, des plages documentées, et des choix clairs par VLAN/SSID.

Pour une méthode simple (adressage IP et noms, tous protocoles confondus) : Réseau d’hôtel : organiser les adresses et les noms des équipements.

Choisir entre dual‑stack et IPv6‑only (NAT64/DNS64) : une grille de décision

Choisir plutôt le dual‑stack si…

• vous avez beaucoup d’équipements hétérogènes (IoT/OT, TV, décodeurs, solutions tierces) dont vous ne maîtrisez pas le comportement IPv6,
• vous voulez réduire le risque de compatibilité à court terme,
• vos outils d’exploitation/sécurité ne sont pas encore outillés pour traiter IPv6 au même niveau que l’IPv4 (tableaux de bord, parsers, corrélation, runbooks).

Envisager IPv6‑only + NAT64/DNS64 si…

• vous cherchez à standardiser un segment (souvent le Wi‑Fi invités) et à limiter l’extension d’IPv4 interne,
• vous pouvez conduire un plan de tests réaliste (panel d’appareils + scénarios),
• vous acceptez d’introduire une dépendance forte à la chaîne DNS64/NAT64, et vous l’exploitez comme un service critique (monitoring, logs, procédures).

Compromis fréquent (et souvent raisonnable en hôtellerie)

• Cœur/distribution : dual‑stack, pour garder de la flexibilité.
• Wi‑Fi invités : dual‑stack au départ (stabiliser sécurité + exploitation), puis évaluer IPv6‑only sur la base de tests et de retours support.
• IoT/OT : dual‑stack (ou IPv4 segmenté) tant que la qualification équipement n’est pas faite.

Plan de déploiement progressif (orienté risques)

Étape 0 — Préparer l’exploitation avant d’activer IPv6 en production

• Inventorier les dépendances : firewall, cœur réseau, contrôleur Wi‑Fi/portail captif, DNS, authentification, supervision, SIEM/logs.
• Définir des critères d’acceptation : règles IPv6 équivalentes IPv4, journaux exploitables, procédure de dépannage, et capacité de retour arrière maîtrisée.

Étape 1 — Piloter en dual‑stack sur un périmètre limité

• Choisir un périmètre pilote (un bâtiment, un SSID, un étage, un groupe de chambres test).
• Observer les symptômes « utilisateur » (latences, applis qui se comportent différemment) et les symptômes « exploitation » (logs incomplets, règles manquantes).
• Réviser la politique firewall et la journalisation jusqu’à une symétrie IPv4/IPv6 crédible.

Étape 2 — Industrialiser l’outillage et les runbooks

• Supervision : visibilité sur l’état IPv6 (résolution, sessions, routage interne, dépendances DNS).
• Runbooks : diagnostic Wi‑Fi invité, diagnostic DNS, diagnostic portail captif, diagnostic « certaines apps ne marchent pas ».

Étape 3 — Si pertinent, évaluer IPv6‑only + NAT64/DNS64 sur un segment

• Valider le couple NAT64 + DNS64 comme une chaîne opérationnelle (logs, supervision, procédures). RFC 6146 / RFC 6147
• Tester explicitement les cas « à risque » : applis ou équipements qui utilisent des littéraux IPv4, ou des comportements inattendus.
• Documenter la stratégie pour les terminaux et scénarios qui ne passent pas (y compris l’évaluation d’un mécanisme de type 464XLAT selon vos contraintes). RFC 6877

Check-list de recette (tests réalisables) avant généralisation

Cette liste est volontairement orientée « tests que l’on peut exécuter », sans supposer un produit ou un constructeur.

• Parcours Wi‑Fi invités : portail captif accessible et cohérent en IPv4/IPv6 (DNS, HTTP(S), redirections, certificats), et règles pré‑auth/post‑auth appliquées dans les deux familles.
• Expérience applicative : panel représentatif (iOS/Android/Windows/macOS + TV/décodeurs utilisés), tests répétables (jour/soir, charge variable).
• DNS : résolution cohérente, capacité à diagnostiquer « DNS répond mais l’app ne marche pas », et logs exploitables (notamment si DNS64 est activé).
• Sécurité : politique firewall IPv6 existante (pas seulement « autoriser tout »), segmentation effective, journalisation utile au support.
• Traçabilité : capacité à relier un incident à une session (SSID/VLAN, borne, période, identité/portail, événements contrôleur).
• Modes dégradés : que se passe‑t‑il si le DNS tombe ? si le portail est indisponible ? si la chaîne NAT64/DNS64 est dégradée ?

Questions à poser aux intégrateurs et fournisseurs (AMO / maîtrise d’ouvrage)

Ces questions servent à obtenir des réponses vérifiables (documentation, POC, recette), sans présumer des capacités d’un constructeur.

• Le contrôleur Wi‑Fi et le portail captif gèrent‑ils des politiques strictement équivalentes en IPv4 et IPv6 (pré‑auth, post‑auth, walled garden) ?
• Le firewall permet‑il de définir des objets/règles IPv6 avec la même granularité et le même niveau de logs qu’en IPv4 ?
• Le DNS récursif supporte‑t‑il DNS64 (si vous visez IPv6‑only), et comment se font supervision et export des logs ?
• Pour NAT64 : quels journaux de traduction sont disponibles, et comment corréler un incident « client » à une session traduite ? RFC 6146
• Les outils SIEM/supervision de l’hôtel traitent‑ils IPv6 correctement (ingestion, parsers, corrélation) ?
• Quelle est votre stratégie de tests (panel appareils, TV/décodeurs, applications), et votre stratégie pour les exceptions (appareils incompatibles) ?

À retenir

• En hôtellerie, dual‑stack est souvent le meilleur point de départ : compatibilité BYOD, migration progressive, qualification des lots hétérogènes.
• IPv6‑only + NAT64/DNS64 peut être excellent sur certains segments (souvent invités), à condition d’assumer une chaîne DNS64/NAT64 conçue comme un service critique, et validée par une recette réaliste. RFC 6146 / RFC 6147
• Le risque le plus coûteux n’est pas « IPv6 ne marche pas », mais « IPv6 marche assez pour être utilisé… sans être correctement filtré, journalisé et supportable ». Les mécanismes côté clients (Happy Eyeballs) peuvent masquer une partie des symptômes sans régler la cause. RFC 8305

Sources et documentation (périmètre de ce guide)

• RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification.
• RFC 6146 — Stateful NAT64.
• RFC 6147 — DNS64.
• RFC 6877 — 464XLAT.
• RFC 8305 — Happy Eyeballs v2.
• RFC 8981 — Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6.
• RFC 9099 — Operational Security Considerations for IPv6 Networks.

Si vous préparez une rénovation ou une mise à niveau réseau (Wi‑Fi, IPTV, segmentation, exploitation), l’enjeu est surtout de transformer ces choix en exigences testables et en procédures support. Domocasa peut vous accompagner en AMO pour cadrer l’architecture cible, la recette et les modes dégradés, avant l’appel d’offres.