Summary

  • Entre 2015 et 2019, les avis de NANOG séparaient surtout un accès protégé d’un accès Legacy ouvert. En 2022, un SSID IPv6-only est devenu un troisième choix explicite; en juin 2023, NANOG a aussi annoncé le passage de 802.1X à une clé WPA3 partagée et expérimenté un accès OWE.
  • De NANOG 89 à NANOG 97, les trois fonctions reviennent avec une remarquable stabilité, tandis que changent les acteurs crédités pour la connectivité, le Wi-Fi et le routage de bord. Ces crédits ne révèlent ni contrats, ni topologie, ni critères de recette, ni répartition complète des responsabilités.
  • Le SSID IPv6-only est une épreuve réelle pour les terminaux. Son libellé ne prouve toutefois ni NAT64, ni DNS64, ni 464XLAT, ni accès aux destinations IPv4-only, ni compatibilité des applications.
  • Une note d’exploitation après chaque réunion pourrait publier des agrégats, les incidents significatifs, le modèle de joignabilité IPv6 et une confirmation de conservation/démontage, sans exposer journaux bruts, identifiants de terminaux ou configurations sensibles.

Une promesse placée au bord du réseau

L’avis de bienvenue de NANOG 97 remercie Ziply Fiber pour la connectivité Internet et HPE pour le routage de bord, puis présente trois SSID. NANOG utilise WPA3 et la clé commune nanognanog. NANOG-Legacy est ouvert, sans chiffrement, sur 2,4 et 5 GHz. NANOG-V6 Only est également ouvert et non chiffré; il n’offre pas d’IPv4 ni de DHCP. Les messages diffusés pendant la réunion reprennent la même liste.

Ces textes fixent ce qui était proposé au public présent. L’avis préalable décrit l’intention de service; la répétition pendant l’événement montre que NANOG continuait d’orienter les usagers vers ces accès. Aucun des deux ne constitue une mesure de disponibilité ou une preuve que chaque terminal s’est associé et a atteint ses destinations.

Les trois choix ne forment pas un classement simple. Le réseau principal privilégie une protection de liaison avec une clé connue de tous les destinataires de l’avis. Legacy privilégie la compatibilité en renonçant explicitement à cette protection. IPv6-only transforme une contrainte de protocole en choix visible. Ils répartissent différemment protection, compatibilité et expérimentation.

Le mot « engagement » doit donc rester modeste. Il ne s’agit pas d’un contrat de niveau de service. NANOG annonce qu’en choisissant tel nom, l’utilisateur trouvera certaines conditions élémentaires. Il peut vérifier la présence du SSID, le besoin d’une clé et l’absence d’un bail IPv4. Il ne peut déduire de cette seule fiche la sécurité de bout en bout, la qualité radio, la compatibilité applicative ou le temps de rétablissement.

Avant les trois SSID

La structure actuelle résulte de plusieurs ajustements. En janvier 2015, pour NANOG 63, l’organisation disait vouloir simplifier et normaliser les informations Wi-Fi. Elle distinguait un accès protégé à 5 GHz, un autre à 2,4 GHz et un réseau Legacy ouvert. Le problème d’interface était alors l’orientation des terminaux entre bandes préférées et solution de repli.

Pour NANOG 69 en 2017, deux SSID étaient publiés: un réseau 802.1X protégé et un Legacy ouvert. Le texte disait que le réseau de conférence visait la haute disponibilité et la démonstration des bonnes pratiques du secteur. Un avis de 2019 conservait cette opposition entre accès protégé et accès de compatibilité.

Une intention n’est pas un résultat. La « haute disponibilité » n’était accompagnée sur ces pages ni d’un objectif chiffré, ni d’un test de bascule, ni d’un relevé d’incidents. L’expression renseigne sur ce que NANOG voulait incarner, pas sur ce qu’un observateur indépendant a mesuré.

En octobre 2022, à NANOG 86, IPv6-only apparaît aux côtés du réseau protégé et de Legacy. L’avis de NANOG 87 reconduit les trois accès avec 802.1X pour le principal et fournit une adresse d’assistance technique.

La transition la plus instructive se lit dans l’avis de NANOG 88, en juin 2023. NANOG y annonce l’abandon de 802.1X au profit d’une clé WPA3 partagée sur le réseau principal, disponible en 2,4, 5 et 6 GHz. Legacy et IPv6-only subsistent. Un quatrième accès OWE est également proposé, avec chiffrement pour les terminaux compatibles.

OWE ne réapparaît pas comme quatrième choix stable dans les avis ultérieurs examinés. Cette disparition est aussi instructive que son introduction: une configuration de réunion ne doit pas être transformée en règle intemporelle. Le réseau temporaire permet d’essayer, de corriger et de simplifier. À partir de NANOG 89, c’est le trio principal/Legacy/IPv6-only qui devient la continuité observable.

Les fonctions restent, les noms de fournisseurs tournent

L’avis de NANOG 89 crédite AT&T pour la connectivité, Cisco Meraki pour le sans-fil et Juniper Networks pour le routage de bord. Il précise que le sous-réseau IPv6-only ne comporte ni passerelle IPv4 ni serveur DHCP.

À NANOG 90, Charter Communications remplace AT&T pour la connectivité; Cisco Meraki et Juniper restent associés aux deux autres fonctions. À NANOG 91, Washtenaw Fiber assure la connectivité déclarée. L’avis de NANOG 93 répète les trois réseaux et renvoie vers [email protected].

Les informations de NANOG 94, conservées dans l’archive de la liste attendee, citent AT&T et HPE Juniper Networks. Pour la réunion conjointe NANOG 95/ARIN, les noms des SSID deviennent NANOG-ARIN, mais leurs trois fonctions restent les mêmes. Ce marquage commun ne permet pas de conclure qu’ARIN a conçu, possédé ou exploité l’ensemble du réseau.

À NANOG 97, Ziply Fiber apparaît pour la connectivité et HPE pour le bord. L’interface de choix résiste donc mieux au temps que la composition des contributeurs.

Cette séparation publique des rôles est utile. Elle rappelle qu’un « réseau » temporaire agrège circuits, Wi-Fi, bord, infrastructure hôtelière, assistance et décisions de configuration. Mais un crédit n’est pas une matrice de contrôle. Le mot connectivité ne prouve pas deux chemins physiques indépendants ni une bascule réussie. Le routage de bord ne dit pas qui détenait les configurations ou autorisait un changement. Le sans-fil ne dit pas qui surveillait le spectre et clôturait les incidents.

Il faut remercier une contribution sans lui attribuer la totalité de l’exploitation. La liste des fournisseurs rend les apports visibles; elle ne distribue pas encore l’acceptation, l’escalade et la responsabilité.

Ce que protège une clé partagée

Une clé publique et commune répond aux contraintes d’un événement. Des centaines de personnes doivent se connecter rapidement; l’information circule dans des messages qui peuvent être transférés et archivés. Cette simplicité définit aussi la limite de l’affirmation possible.

L’avis atteste un accès principal WPA3 à clé prépartagée. Il n’atteste pas des identifiants individuels, une attribution fiable d’un terminal à une personne, ni la sécurité universelle des communications. Sans autre document, on ne peut pas non plus déduire le mode WPA3 précis, l’isolation entre clients ou la protection des trames de gestion pour une édition donnée.

Legacy est décrit sans détour comme ouvert et non chiffré. Cela signifie l’absence de chiffrement au niveau de la liaison. Certaines applications ajoutent leur propre chiffrement; d’autres usages peuvent rester risqués. L’avis ne suffit donc ni à déclarer toute session sûre, ni à déclarer tout usage dangereux.

La compatibilité reste un besoin légitime. Un appareil ancien peut ne pas négocier le mode préféré; un ingénieur peut tester un équipement hérité; un accès ouvert peut aider à distinguer une panne d’authentification d’un défaut radio ou applicatif. Supprimer Legacy déplacerait le risque vers l’exclusion de certains terminaux.

Reste une question sans réponse publique: combien de clients en ont réellement eu besoin ? Les avis ne ventilent ni les associations, ni les échecs, ni les retours vers le réseau principal. « Legacy » est donc la promesse d’une issue de compatibilité, pas la preuve chiffrée de sa demande.

IPv6-only ne veut pas dire « tout Internet sans IPv4 »

Le troisième SSID est le plus facile à surinterpréter. Dans une réunion d’opérateurs, soumettre de vrais terminaux à l’absence d’IPv4 peut révéler des dépendances qu’une présentation ne montre pas. Une application fondée sur une adresse IPv4 littérale peut échouer; une autre peut fonctionner nativement en IPv6.

Or les avis détaillés indiquent seulement l’absence de passerelle IPv4 et de DHCP. Ils ne déclarent ni NAT64, ni DNS64, ni 464XLAT, ni signal IPv6-Only Preferred de la RFC 8925. Ils ne publient pas le comportement des résolveurs, la capacité de traduction, les préfixes ou les tests applicatifs.

La RFC 8925 décrit un mécanisme par lequel un hôte capable peut renoncer à une adresse IPv4 sous certaines conditions réseau. La RFC 8683 traite des choix NAT64, DNS64 et 464XLAT dans les réseaux d’opérateur et d’entreprise. Ces textes ne prouvent aucune configuration de NANOG. Ils montrent pourquoi « pas d’IPv4/DHCP » n’est pas une description complète de la joignabilité.

Le SSID établit donc une réalité: NANOG a offert aux personnes présentes une surface d’accès contrainte par le protocole. Il n’établit ni taux d’adoption, ni succès de toutes les applications, ni effet éducatif, ni déploiement ultérieur chez leurs employeurs.

La clinique IPv6 de NANOG 93 proposait présentations, travaux pratiques et tableau blanc. Elle prouve une activité pédagogique distincte. Une inscription à la clinique ne mesure pas le Wi-Fi de production; un accès fonctionnel ne prouve pas que la formation a causé une migration ultérieure.

Une publication agrégée suffirait: modèle de joignabilité prévu, associations ou baux définis par SSID, grandes catégories d’échec, disponibilité pendant la fenêtre prévue. Le test deviendrait reproductible sans transformer les personnes présentes en jeu de données public.

Un point de contact n’est pas un compte rendu d’incident

Plusieurs avis fournissent [email protected]; NANOG 97 renvoie vers l’assistance. Une personne présente sait où signaler un problème. C’est un vrai progrès par rapport à un service sans interlocuteur visible.

L’adresse ne dit cependant rien des heures de couverture, du délai de première réponse, du nombre de demandes, de leur sévérité, de la cause, de la correction ou de la clôture. Une organisation interne peut exister sans être publique; l’avis ne permet simplement pas de l’évaluer.

Il faut résister à deux raccourcis. L’absence de rapport public ne prouve pas l’absence d’incident. L’absence de politique spécifique aux journaux réseau ne prouve ni l’absence de collecte, ni une surveillance massive. Dans le corpus examiné, ces questions restent inconnues.

Cette prudence empêche de transformer le manque de données en compliment ou en accusation. Elle laisse à NANOG la possibilité de rendre les résultats visibles sans publier les cas individuels.

Huit champs après la fermeture du réseau

Une note d’une page pourrait suffire.

Fenêtre de service. Heures prévues de début et de fin, et état des trois SSID pendant cette période. Si la mesure est partielle, ne pas fabriquer un pourcentage global.

Matrice des rôles. Acteurs chargés de la connectivité, du Wi-Fi, du bord, de la livraison hôtelière et de l’assistance NANOG. Une responsabilité partagée doit rester partagée.

Dénominateurs d’accès. Associations, baux ou sessions agrégés par SSID avec définition du compteur. Une adresse MAC n’est pas une personne; la randomisation et les nouvelles tentatives doivent être signalées.

Modèle IPv6. Indiquer si le SSID visait uniquement l’IPv6 natif ou offrait une traduction nommée vers les destinations IPv4-only. Le design ne vaut pas preuve de réussite universelle.

Incidents significatifs. Intervalle, surface touchée, symptôme général et correction pour les événements dépassant un seuil publié. Les incidents individuels peuvent être agrégés.

Assistance. Volume, catégories, délai de première réponse et de clôture sous forme de médiane ou de tranche. Un champ non mesuré doit rester non mesuré, pas devenir zéro.

Télémétrie et conservation. Catégories d’association, DHCP, DNS, flux ou sécurité; finalité, rôles autorisés, échéance de suppression ou d’anonymisation. Pas de données brutes.

Démontage. Confirmation que clés temporaires, configurations, accès des fournisseurs et journaux conservés ont suivi la procédure annoncée, avec un rôle responsable.

Cette liste exclut volontairement captures de paquets, MAC des clients, historiques individuels, secrets, contrats privés et détails facilitant une attaque. Rendre un résultat auditable n’impose pas de publier la cible.

L’objection de proportionnalité

La meilleure défense du niveau actuel de publication est solide. NANOG monte un réseau pour quelques jours, dans des hôtels, environnements radio et montages fournisseurs variables, avec des terminaux qu’elle ne gère pas. La priorité des ingénieurs est de connecter et de réparer, non de produire un rapport à chaque édition. Les trois choix et l’adresse d’aide sont déjà plus explicites que le Wi-Fi de nombreuses conférences.

Des schémas détaillés peuvent aider un attaquant. Des statistiques trop fines peuvent réidentifier des personnes. Exiger chaque alerte, configuration et ticket alourdirait le travail et pourrait décourager des notes d’incident franches.

Cette objection justifie une limite, pas le silence complet. Il suffit de publier le résultat au même niveau d’abstraction que la promesse faite au public.

Les procès-verbaux du Steering Committee de 2007 montrent que résilience et responsabilité n’étaient pas étrangères à NANOG. Pour NANOG 40, ils consignent une inquiétude sur l’existence d’un chemin alternatif si le lien « démonstrateur » à 10 Gbit/s rencontrait un problème, mentionnent un contrat pour le Wi-Fi et une présentation XKL du réseau. Cela prouve une discussion de planification en 2007, pas la topologie ou la bascule de NANOG 97.

La discipline à conserver est simple: un plan n’est pas une livraison, un crédit n’est pas un contrôle intégral, deux noms ne prouvent pas deux chemins physiques, une démonstration n’est pas un résultat.

Mesurer le choix sans suivre la personne

Un comptage par SSID peut devenir intrusif s’il est mal conçu. Dans une population limitée, l’heure d’association, un identifiant de terminal, un changement de réseau et un ticket d’assistance peuvent suffire à reconnaître une personne, même après suppression du nom. La publication ne doit donc pas être une copie de journaux « anonymisés ». Elle doit être conçue à partir de la question agrégée.

La question utile est étroite: les trois modes annoncés ont-ils été utilisés, et où se sont concentrées les grandes catégories d’échec ? Elle n’exige ni les sites consultés, ni les requêtes DNS, ni l’employeur, ni le parcours d’un terminal. Un total sur la réunion ou de larges tranches quotidiennes suffit généralement. Une série minute par minute ajouterait surtout un risque de réidentification.

Les incidents peuvent également être regroupés: incompatibilité d’authentification, couverture radio, joignabilité applicative en IPv6, transfert du site hôtelier, par exemple. Une catégorie rare peut être fusionnée ou non publiée. Et zéro ne doit signifier zéro que si le champ a effectivement été mesuré; une absence de collecte reste inconnue.

Cette méthode améliore aussi la qualité des chiffres internes. Une association, un bail DHCP, une adresse MAC et une session ne sont pas la même unité. La randomisation peut faire apparaître plusieurs identités techniques pour un seul appareil. Sur un réseau IPv6-only sans DHCPv4, le nombre de baux IPv4 est évidemment un mauvais dénominateur. Avant de compter, il faut rattacher l’unité à la promesse examinée.

La conservation doit être décrite avec la même précision. « Les journaux ont été supprimés après la réunion » ne veut pas dire grand-chose si les contrôleurs, tableaux de bord, boîtes d’assistance et systèmes des fournisseurs conservent des catégories différentes. NANOG n’a pas besoin de publier chaque emplacement. Elle peut distinguer les données qu’elle contrôle, celles traitées par un contributeur et la règle de conservation applicable.

Enfin, le démontage appartient au service. La clé commune est archivée publiquement pour toujours; sa sûreté après l’événement vient de l’arrêt du SSID ou du changement de configuration, non du secret. Les comptes temporaires, les accès aux contrôleurs et les copies de configuration doivent eux aussi atteindre un état de clôture vérifiable.

Une haute disponibilité adaptée à trois jours

Rendre l’expression vérifiable n’impose pas une formule d’opérateur national. La mesure peut être rapportée à la fenêtre de service prévue et séparée par surface. Un SSID peut rester visible pendant une coupure amont. Internet peut être joignable alors que l’authentification échoue. L’IPv6 natif peut fonctionner alors qu’un service de traduction prévu est en panne. Un seul pourcentage masquerait ces différences.

Un relevé minimal peut distinguer association, configuration d’adresse, DNS, joignabilité Internet et assistance. Ce n’est pas un modèle exhaustif; ce sont les étapes que l’utilisateur rencontre. Un seuil d’incident significatif peut combiner durée et portée, par exemple au-delà d’un intervalle défini ou de plusieurs salles. NANOG peut choisir un autre seuil. L’essentiel est de le fixer avant le récit final.

La redondance demande aussi un vocabulaire propre. Un crédit de connectivité ne promet pas deux chemins. Si plusieurs circuits ou amonts existent, il faut séparer redondance prévue, indépendance physique telle que déclarée par les fournisseurs, et bascule effectivement testée ou observée. Deux sessions logiques empruntant une même infrastructure ne valent pas deux routes physiques. À l’inverse, garder la carte fibre confidentielle n’empêche pas de publier le résultat d’un test de bascule et son critère d’acceptation.

La recette avant ouverture et l’incident en charge sont deux preuves différentes. Une liste de contrôle peut tester la diffusion des SSID, l’association, l’adressage, le résolveur, quelques destinations et le modèle IPv6. Elle ne garantit pas le comportement lorsque des centaines d’appareils arrivent. Le compte rendu doit pouvoir dire: les essais ont réussi, puis tel problème est apparu sous charge. La correction n’efface pas l’incident; l’incident n’annule pas la valeur de la correction.

Le caractère temporaire renforce l’intérêt de ce résumé. Un réseau permanent accumule des séries mensuelles. La conférence ne dispose que d’une fenêtre, puis son infrastructure disparaît. Sans un relevé gelé, le savoir reste dans des boîtes mail et des souvenirs, tandis que l’édition suivante change d’hôtel et de contributeurs.

Legacy doit avoir un test de sortie

Un accès de compatibilité se conserve facilement: sa suppression produit des plaintes immédiates, alors que son maintien distribue silencieusement le risque. Des agrégats peuvent corriger cette asymétrie. NANOG pourrait publier la part des tentatives définies, les causes principales qui ont conduit vers Legacy et la possibilité de corriger ces causes sur le réseau préféré.

Si une classe importante de terminaux ne rejoint pas WPA3, conserver Legacy est défendable, avec avertissements et contrôles adaptés. Si l’usage est presque nul et limité à des appareils de test, un accès sur demande peut suffire. Si des personnes le choisissent parce que son nom paraît plus simple, le problème est peut-être l’information et non la compatibilité.

Le même raisonnement vaut pour OWE. L’avis de juin 2023 prouve que l’option a existé. Son absence ultérieure ne dit pas si elle a échoué, si elle était inutile, si elle a été intégrée ailleurs ou simplement omise des communications. Une phrase de décision — poursuivre, modifier ou retirer, avec motif agrégé — éviterait de faire de ce silence un verdict technique.

Un test de sortie n’est pas une hostilité envers les anciens appareils. Il empêche qu’une exception utile devienne permanente sans être examinée. Une note et quelques agrégats suffisent; il n’est pas question d’instituer une procédure lourde.

Trois obligations, pas trois verdicts

Le réseau principal impose de décrire la protection sans faire d’une clé commune une identité individuelle. Legacy impose d’avertir sur l’absence de chiffrement de liaison et de mesurer si le repli reste nécessaire. IPv6-only impose d’expliquer ce que « only » signifie pour la joignabilité et d’agréger succès et échecs sans publier les utilisateurs.

Tous trois imposent aussi de préserver les frontières entre acteurs. AT&T, Charter Communications, Washtenaw Fiber et Ziply Fiber apparaissent selon les années pour la connectivité; Cisco Meraki, Juniper et HPE apparaissent dans des rôles sans-fil ou de bord. Ces crédits rendent les contributions lisibles, mais ils ne constituent pas la carte complète des décisions et des conséquences.

Le dossier public permet une conclusion positive: NANOG a rendu visible un choix récurrent entre défaut protégé, compatibilité ouverte et essai IPv6-only. C’est plus instructif qu’un SSID d’hôtel unique et plus honnête que de masquer les compromis.

Il ne permet pas de juger comment cette promesse a tenu. Les dénominateurs de connexion, la disponibilité, les incidents, l’assistance et le démontage ne sont pas publiés de manière régulière, et le chemin vers les services IPv4-only n’est pas décrit. Ce sont des limites de preuve, non la preuve d’une ingénierie défaillante ou de contrôles inexistants.

NANOG n’a pas à publier son réseau. Elle peut publier ce qu’il a produit, au niveau exact où elle demande au public de choisir. Les trois SSID énoncent déjà trois obligations; une note courte, sûre et respectueuse de la vie privée dirait si elles ont résisté à la réalité de la salle.

Sources