Calculateur de sous-réseaux IPv4 et IPv6

Situation

L'espace d'adressage de l'entreprise est à définir entièrement. Il y a 150 sites et 16 usines, et les réseaux virtuels dans le cloud prennent place dans le même espace. Les divisions sont réorganisées à quelques années d'intervalle, et les régions dont dépendent les sites changent elles aussi. Il s'agit de décider, avant tout, ce qui va où dans 10/8.

Hypothèses

Pouvoir découper librement 10/8 au sein de l'entreprise. Ne pas avoir à envisager, pour l'instant, qu'une future intégration mélange cet espace avec celui d'une autre entreprise. Pouvoir ajouter d'autres usages plus tard. Pouvoir compter les lignes de filtre qui font référence aux limites.

Allocation

Raisonnement

La première chose à décider dans 10/8, c'est la signification du deuxième octet. Il y a trois options : découper par usage, par organisation ou par géographie.

En bref, on découpe par usage. L'organisation et la géographie changent, l'usage non. Les divisions sont réorganisées à quelques années d'intervalle, et les régions changent de responsable. À l'inverse, une usine ne devient jamais un site de bureaux, et un environnement de test ne devient jamais la production.

Si l'on découpe par organisation, chaque réorganisation impose un choix : déplacer les limites, ou laisser des noms qui ne correspondent plus à la réalité. C'est presque toujours la seconde option qui est retenue, et quelques années plus tard, un autre service occupe le bloc des ventes. Le découpage du document de conception et ce qui se trouve réellement sur les équipements ne concordent alors plus.

Les limites de premier niveau ne peuvent pas bouger, car les filtres sont écrits en partant du principe que 10.16.0.0/12 correspond aux usines. Si une limite bouge, il faut revoir toutes les lignes qui y font référence. Avec 150 sites, 16 usines et le cloud, cela représente des centaines de lignes, et si tout n'est pas basculé en même temps, il y aura une période où le trafic ne passe que dans un sens.

C'est pourquoi on décide le moins possible au départ. En découpant 10/8 en /12, on obtient 16 blocs à attribuer aux usages. On commence avec quatre usages, et on ajoute un bloc quand la place manque. Les blocs ne font que s'ajouter, donc les limites existantes ne bougent pas. N'utiliser que 4 blocs sur 16 semble du gaspillage, mais ne rien avoir à déplacer vaut davantage.

Marge de croissance

Il y a 16 blocs /12 au total. Les quatre usages (commun à l'entreprise, sites, usines et cloud) occupent quatre blocs, et douze restent libres. Pour ajouter un usage, on lui attribue un bloc libre comme 10.64.0.0/12, sans toucher aux limites existantes. Les usages qui apparaissent plus tard, comme les tests ou l'IoT, prennent eux aussi un nouveau bloc au lieu de découper un bloc existant. Le prochain bloc à attribuer se choisit au moment où il devient nécessaire.

Pièges

• Découper le deuxième octet par organisation. L'organisation est réorganisée à quelques années d'intervalle alors que les limites ne peuvent pas bouger : les noms et la réalité divergent durablement. On découpe par usage.
• Créer d'emblée de nombreux usages très fins. Les blocs inutilisés se multiplient, et chaque nouvelle demande oblige à trancher à quel usage elle appartient. On commence avec quatre environ et on en ajoute au besoin.
• Emprunter une partie du bloc voisin pour un usage à court de place. Une limite apparaît au milieu du bloc, et désormais, seul ce bloc mélange deux usages. Si la place manque, on attribue un bloc entier.
• Conserver le résultat du découpage sans ses raisons. Le successeur peut lire à quoi sert chaque bloc, mais pas pourquoi on a découpé par usage, et la proposition de redécouper par organisation revient régulièrement.
• Prendre en dernier la plage commune à l'entreprise. Les blocs pratiques partent en premier, et ce qui est commun à l'entreprise se retrouve dispersé dans des blocs éloignés. Ce qui est commun à l'entreprise prend le premier bloc.

Situation

Une entreprise d'environ 100 personnes place ses équipements de terrain et de test dans la plage 192.168. Chaque fois qu'il est question de relier des sites avec un partenaire commercial ou un prestataire, les adresses entrent en conflit avec celles des locaux de l'autre partie et il faut les coordonner. Les connexions en télétravail entrent aussi parfois en conflit avec les routeurs sans fil personnels des employés.

Hypothèses

Il n'est pas toujours possible de connaître à l'avance les adresses utilisées dans les locaux de l'autre partie. On peut séparer les équipements routés vers l'extérieur de ceux qui ne le sont pas. Changer plus tard l'adresse d'un équipement exige une intervention sur place et une reconfiguration. 10/8 est également disponible.

Allocation

Raisonnement

192.168.0.0/16 n'appartient pas qu'à l'entreprise. Les équipements domestiques, les routeurs sans fil personnels et les locaux des partenaires et prestataires utilisent le même espace. On sait bien que les valeurs par défaut se concentrent sur 192.168.0 et 192.168.1, mais le problème ne s'arrête pas là. Les valeurs par défaut des petits équipements se dispersent aussi sur 192.168.10, 192.168.100 et d'autres, et on ne peut généralement pas savoir à l'avance ce qu'utilise l'autre partie.

Si l'on évite chaque bloc en conflit au cas par cas, la liste des blocs évités ne cesse de s'allonger. Après dix ans d'exploitation, elle compte des dizaines de blocs, et chaque nouveau partenaire doit être vérifié par rapport à cette liste. Ce sont des personnes qui vérifient, donc des cas passent entre les mailles.

On fait donc l'inverse. On fixe la plage utilisée par le bit de poids fort : seule la moitié où le troisième octet vaut 128 ou plus appartient à l'entreprise. On renonce à la moitié de l'espace, mais la décision n'est prise qu'une fois. Une entreprise d'environ 100 personnes a besoin de moins de 10 blocs, donc 128 suffisent largement.

On limite aussi ce qu'on y place. Seuls les équipements qui ne sont routés ni vers d'autres entreprises ni vers d'autres sites ont leur place dans cet espace. Si l'on sait que les conflits y sont inévitables, il suffit de n'y placer que ce qui ne souffre pas d'un conflit. Tout ce qui est visible depuis l'autre bout d'une liaison entre sites, ou qui sort vers une interconnexion, prend ses adresses dans 10.0.0.0/8.

Marge de croissance

L'entreprise n'utilise que la moitié où le troisième octet vaut 128 ou plus, et y occupe 4 blocs sur 128. L'autre moitié, 192.168.0.0/17, reste libre, et même si les partenaires se multiplient, on ne vérifie pas bloc par bloc. La décision tient en une seule vérification : le troisième octet vaut-il 128 ou plus ? Quand un équipement doit être routé vers l'extérieur, il ne va pas dans cet espace et prend ses adresses dans 10.0.0.0/8. Même si les équipements se multiplient, la moitié utilisée suffit.

Pièges

• Découper en supposant que tout 192.168 appartient à l'entreprise. Chaque interconnexion apporte un conflit, chacun est traité en évitant un bloc, et les traces des blocs évités s'éparpillent. On fixe la plage utilisée par le bit de poids fort.
• Tenir une liste des blocs en conflit pour les éviter. Chaque nouveau partenaire impose une vérification, et comme ce sont des personnes qui la font, des cas passent entre les mailles. On ramène la décision à une seule vérification du bit de poids fort.
• Placer dans cet espace des équipements visibles de l'extérieur. En cas de conflit avec les locaux de l'autre partie, seul le côté de l'entreprise peut bouger, et il faut changer les adresses des équipements. Ce qui sort vers l'extérieur prend ses adresses dans 10.0.0.0/8.
• Se mettre à utiliser la moitié inutilisée parce que la laisser vide semble du gaspillage. Les blocs mis en service ne se récupèrent pas ; on ne gagne rien et on perd la simplicité de la décision. Pour environ 100 personnes, 128 blocs suffisent largement.

Situation

Siège ou agence d'une centaine d'employés sur un ou deux étages. On y utilise à la fois le filaire et le sans-fil, avec un serveur de fichiers et un NAS hébergés sur place. C'est la configuration la plus typique.

Hypothèses

Disposer d'au moins un commutateur de niveau 3 ou d'un routeur compatible VLAN. Le DHCP peut être assuré par un équipement réseau ou par un serveur. Prévoir que l'effectif puisse être multiplié par 1,5 dans les trois ans.

Allocation

Raisonnement

À une centaine de personnes, la première question est de savoir si un seul /24 suffit. La réponse : pour le filaire seul, il suffit, mais il ne faut pas tailler un seul /24 pour tout le site. Un /24 suffit à lui seul pour les clients filaires. Mais si l'on compte les smartphones professionnels et les connexions sans fil des ordinateurs portables, chaque personne a en réalité deux ou trois appareils, et les 254 adresses d'un /24 se remplissent vite.

On réserve donc un /22, découpé en /24 et /26 à l'intérieur. Les clients filaires et le sans-fil reçoivent chacun leur propre /24, pour que l'épuisement d'un pool DHCP ne se propage pas à l'autre. Serveurs et gestion restent en /26, car à cette échelle ils dépassent rarement 60 équipements, et leur attribuer davantage ferait perdre la lisibilité du troisième octet.

Donner un sens au troisième octet est aussi délibéré. Avec 0 = filaire, 1 = équipements à IP fixe, 2 = sans-fil et 3 = phase 2, un coup d'œil à une capture de paquets ou à un journal suffit pour savoir de quel segment il s'agit. Cette lisibilité se traduit directement en rapidité de résolution des incidents.

Marge de croissance

Comme 10.20.3.0/24 reste entièrement libre, même si l'effectif est multiplié par 1,5, on peut étendre le sans-fil à un /23 ou ajouter un segment par service. Si le /26 des serveurs devient étroit, on déplace les imprimantes de 10.20.1.128/27 vers 10.20.1.192/27, puis la gestion des équipements vers le 10.20.1.128/26 ainsi libéré ; les serveurs peuvent alors doubler en 10.20.1.0/25. Pour ajouter un site, on continue avec 10.21.0.0/22, 10.22.0.0/22, etc., et on les agrège en 10.20.0.0/14.

Pièges

• Utiliser 192.168.1.0/24 ou 192.168.0.0/24 sur le réseau d'entreprise. Ces plages entrent en conflit avec les valeurs par défaut des routeurs domestiques, et le routage se casse lors des connexions VPN en télétravail. Le plus sûr est de découper dans 10/8.
• Regrouper les clients sans fil et filaires dans le même segment. Le jour où l'on veut ajouter un SSID invité, il faut refaire le plan d'adressage. Les séparer dès le départ ne coûte presque rien.
• Mélanger les adresses de gestion des équipements réseau dans un segment client. Les ACL ne peuvent plus restreindre séparément l'accès de gestion, et les audits le relèvent systématiquement.
• Utiliser le /24 de réserve pour un besoin immédiat « parce qu'il est libre ». Une réserve vaut justement parce qu'on ne l'utilise pas ; en la nommant « phase 2 » plutôt que « réserve », on la protège mieux.

Situation

Site d'une centaine de places sans attribution fixe. Pour un effectif de 120 personnes, le taux de présence au bureau varie de 40 % à 80 % selon les jours. Tout le monde se déplace avec un ordinateur portable, et les prises filaires ne subsistent que dans les salles de réunion et à quelques places fixes. Une dizaine de personnes de passage, intérimaires ou prestataires sur site, sont présentes en permanence.

Hypothèses

Disposer d'un sans-fil couvrant tout le site, les employés pouvant travailler sur leurs appareils uniquement en sans-fil. Pouvoir régler la durée du bail DHCP par segment. Pouvoir retrouver après coup la présence réelle de chaque jour, par exemple à partir des registres d'entrée et de sortie. Aucun système de réservation de places n'est en place.

Allocation

Raisonnement

Pour dimensionner le pool, les premiers chiffres qui se présentent sont les 100 places et l'effectif de 120. On écarte d'abord le nombre de places. On considère ensuite le nombre d'appareils à la présence maximale : avec 80 % de présence, cela fait 96 personnes et, comme chacune a un ordinateur portable et un smartphone professionnel, 192 appareils. Jusque-là, les 254 adresses d'un /24 suffisent.

C'est ensuite que le calcul se trompe. En flex office, on ne sait pas qui viendra aujourd'hui. Avec une durée de bail de 24 heures, les adresses des appareils des personnes venues hier mais pas aujourd'hui sont toujours actives. Une présence qui varie de 40 % à 80 % signifie qu'il y a des jours où peu de personnes reviennent deux jours de suite. Si un jour à 40 % (48 personnes) est suivi d'un jour à 80 % (96 personnes) presque sans visages communs, le nombre de personnes venues sur les deux jours approche l'effectif de 120, et les baux actifs atteignent jusqu'à 240 appareils. C'est 94 % des 254 adresses d'un /24, et il n'en reste que 14. L'épuisement ne survient pas le jour le plus chargé, mais le jour où les visages changent. Ce qu'il faut compter, ce n'est pas la présence maximale, mais le nombre de personnes qui peuvent venir pendant une durée de bail, autrement dit un chiffre proche de l'effectif.

Suffit-il alors de raccourcir le bail ? Il y a une limite basse. Les portables refermés pendant la pause déjeuner et les réunions de l'après-midi restent trois à quatre heures sans communiquer, et avec un bail de 2 heures, certains appareils obtiennent une autre adresse à leur retour. La limite haute est fixée par la taille du pool, la limite basse par la façon de travailler. Pour satisfaire les deux, il n'y a pas d'autre choix qu'un /23 pour le pool. Avec 510 adresses, il reste 53 % de libre même avec 240 appareils.

Avec un /23, la correspondance entre le troisième octet et le segment disparaît, mais sur ce site, éviter l'épuisement passe avant la lisibilité. Si des appareils qui communiquent en se déplaçant en permanence doivent partager le même pool, une décision distincte s'impose.

Marge de croissance

Le 10.16.10.0/23 voisin n'est pas laissé libre pour l'avenir, mais pour que le pool puisse s'étendre comme un seul sous-réseau. Un pool ne s'étend pas par morceaux séparés : pour passer du /23 à un /22, le /23 adjacent doit être entièrement libre. Le seuil de décision est fixé à un effectif de 210, car si presque tout le monde vient sur deux jours, cela fait 420 appareils, soit 82 % des 510 adresses du bloc /23 actuel. On fusionne alors le bloc adjacent pour former 10.16.8.0/22, sans changer la durée du bail. C'est cette contrainte qui a repoussé le filaire comme les serveurs vers 10.16.12.0/24. Si les conditions de libération ne sont pas fixées à l'avance, l'espace libre sera toujours pris pour un autre usage.

Pièges

• Dimensionner le pool d'après le nombre de places. Si l'on découpe un /25 parce qu'il y a 100 places, il ne suffit plus dès qu'on compte deux appareils par personne et le personnel de passage, et il est épuisé dès la première semaine d'exploitation. On compte les appareils, pas les places.
• Raccourcir la durée du bail pour accélérer la rotation et éviter l'épuisement. Les appareils qui reviennent après le déjeuner ou une réunion obtiennent une autre adresse et perdent leurs connexions, mais comme la coupure ne se produit qu'au moment du retour, elle ne se reproduit pas et personne ne la signale.
• Placer les appareils du personnel de passage dans le même pool que ceux des employés. Le nombre d'appareils estimé à partir de l'effectif s'écarte sans cesse de la réalité, et à chaque hausse d'effectif on ne peut plus expliquer combien d'adresses ont manqué. On sépare ce qui est prévisible de ce qui ne l'est pas.
• Conserver l'attribution d'IP fixes aux prises filaires. En flex office, une personne différente s'installe chaque jour à la même prise, si bien que la correspondance entre adresses et utilisateurs se défait vite et qu'il ne reste que le registre d'adresses. Le filaire aussi est servi par DHCP.

Situation

150 sites au total : 1 siège, 8 hubs régionaux et 141 bureaux commerciaux et entrepôts. Chaque site est relié au siège par un hub régional, et les routes sont agrégées aux hubs régionaux puis transmises vers l'amont. Les numéros de site servent déjà à la gestion des actifs ainsi que dans les formulaires et les états, et ont été attribués dans l'ordre d'ouverture. Chaque année, quelques sites ouvrent et quelques-uns ferment.

Hypothèses

Chaque hub régional peut annoncer ses sites sous une seule route. Un système de numéros de site existe déjà, et les sites ne peuvent pas être renumérotés pour les besoins du plan d'adressage. Aucun site ne dépasse 1 000 appareils. La région à laquelle appartient chaque site ne change pas avant plusieurs années.

Allocation

Raisonnement

On agrège pour que 150 sites ne remontent pas vers l'amont sous forme de 150 routes. Mais ce que l'agrégation exige, ce sont des blocs d'adresses contigus, pas des numéros de site contigus. Si l'on confond les deux, toute la conception est perdue.

Les numéros de site existent déjà. Ils servent à la gestion des actifs, aux formulaires et aux états, ont été attribués dans l'ordre d'ouverture et n'ont aucun lien avec les régions. Si on les reporte tels quels sur le deuxième octet, le hub de la région 3 se retrouve avec un ensemble dispersé, comme les sites 3, 17, 42 et 88. Des blocs dispersés ne se regroupent pas en une seule route, donc 150 routes remontent toujours. Renuméroter pour agréger est impossible : les numéros sont inscrits dans les formulaires, les états et la façon dont on désigne les sites.

On inverse donc l'ordre. On attribue d'abord un bloc à l'unité d'agrégation, c'est-à-dire au hub régional, puis on distribue les numéros de site comme identifiants à l'intérieur de ce bloc. Chacune des 8 régions reçoit un deuxième octet, et chaque site un bloc /22 qui lui est propre. Une région peut contenir jusqu'à 64 sites. Avec 150 sites, même la plus grande région n'en compte que 24 : tout tient, et 8 routes remontent. Même si les sites doublent pour atteindre 300, on reste à 8.

Le prix à payer est que le numéro de site ne se lit plus dans l'adresse. Le rendre lisible obligerait à renoncer à la contiguïté au sein des régions. Pour traiter les incidents, il ne faut pas une règle de numérotation, mais une table de correspondance entre numéros de site et blocs.

Marge de croissance

Les blocs régionaux utilisent les deuxièmes octets 1 à 8, et le 0 sert aux usages communs à l'entreprise. Les sept blocs 9 à 15 sont laissés libres, pour ajouter des régions et pour le deuxième bloc régional attribué à une région qui dépasse 64 sites. Ces numéros ne sont pas contigus : on les retrouve dans la table de correspondance. À partir de 10.16.0.0/12, on ne touche à rien : cet espace est gardé pour les acquisitions et l'accueil d'autres activités.

Pièges

• Faire correspondre directement les numéros de site aux adresses. Les numéros suivent l'ordre d'ouverture et n'ont aucun lien avec les régions : les sites d'un même hub se retrouvent dispersés, et autant de routes que de sites remontent toujours vers l'amont. On distribue les numéros à l'intérieur du bloc régional.
• Prendre les adresses des liaisons entre sites dans le bloc du site lui-même. Si l'autre extrémité est un site d'une autre région, des adresses du bloc de cette région se retrouvent dans l'autre région, et des routes plus spécifiques remontent pour elles. On prend les liaisons dans un bloc commun, hors des blocs de site.
• Ajouter des segments dans un site en franchissant la limite de son bloc. La partie qui déborde n'est pas couverte par l'agrégation, et une route plus spécifique remonte pour ce seul site. On n'ajoute qu'à l'intérieur du bloc, et on attribue un deuxième bloc une fois celui-ci dépassé.
• Exiger que le numéro de site se lise dans l'adresse. Le rendre lisible oblige à renoncer à la contiguïté au sein des régions, et l'agrégation ne fonctionne plus. Ce qu'il faut, ce n'est pas une règle de numérotation, mais une table de correspondance.
• Rattacher un seul site à un autre hub régional pour des raisons géographiques. Ses adresses restent dans le bloc de la région d'origine : en amont apparaissent côte à côte le bloc régional et une route propre à ce seul site. Si un site change de hub, on déplace aussi ses adresses.

Situation

Dans un réseau comptant 300 liaisons point à point ou plus, on fixe la longueur de préfixe des liaisons. Les équipements sont de générations mélangées : anciens équipements, équipements spécialisés et équipements virtuels cohabitent. Une uniformisation en /31 a été proposée pour économiser des adresses.

Hypothèses

Pouvoir lister le modèle et la génération des équipements aux deux extrémités de chaque liaison. Pouvoir vérifier à l'avance si un équipement prend en charge le /31 ou non. Les attributions se font en un seul endroit. Changer plus tard les adresses d'une liaison impose de réécrire la configuration et la supervision.

Allocation

Raisonnement

Un /30 compte quatre adresses dont deux seulement sont utilisables ; un /31 utilise les deux. Le besoin en adresses est divisé par deux.

Mais comme économie, cela ne signifie rien. Avec 352 liaisons, le /30 consomme 1 408 adresses et le /31 en consomme 704. L'écart de 704 ne représente qu'environ 1 pour cent du bloc /16 réservé aux liaisons. Un écart aussi faible ne justifie pas de changer de décision.

Le critère décisif est que tous les équipements suivent. Tous les équipements ne prennent pas en charge le /31 pour autant. Un ancien équipement, un équipement spécialisé ou un équipement virtuel peut ne pas le faire. Chaque liaison a un équipement à chaque extrémité, donc il suffit que l'un d'eux ne le prenne pas en charge pour que cette liaison doive être en /30 malgré tout.

Mélanger les deux change la procédure d'attribution. Deux tailles cohabitent dans le pool, et chaque attribution oblige à vérifier la prise en charge des équipements aux deux extrémités. À 10 liaisons par mois, cela fait 120 vérifications par an. Économiser 704 adresses ne vaut pas 120 vérifications par an.

On uniformise donc. Si tous les équipements le prennent en charge, /31 ; s'il reste ne serait-ce qu'un équipement qui ne le fait pas, /30 partout. Si le mélange est inévitable, on sépare les plages pour ne pas avoir à vérifier à chaque attribution.

Autre point. Une liaison découpée une fois en /30 ne passe pas en /31, même quand ses équipements sont remplacés. La faire passer oblige à changer ses adresses, ce qui réécrit la configuration et les noms dans la supervision. On ne part pas du principe d'une migration ultérieure.

Marge de croissance

Par défaut on utilise /30, et seuls les tronçons dont la prise en charge est confirmée sont découpés dans la plage /31 dédiée. On sépare les plages pour ne pas avoir à vérifier la prise en charge des équipements lors de l'attribution. Un tronçon n'entre dans la plage /31 que lorsque les équipements des deux extrémités ont été remplacés et leur prise en charge confirmée. La croissance est prise dans 10.161.16.0/21. Même quand tous les équipements ont été remplacés, les liaisons /30 existantes ne sont pas converties ; seules les liaisons nouvellement créées sont découpées en /31 dès le départ.

Pièges

• Choisir /31 pour économiser des adresses. L'économie représente environ 1 pour cent du bloc des liaisons et ne justifie pas de changer de décision. Le critère décisif est que tous les équipements suivent.
• Mélanger les deux tailles dans la même plage. Chaque attribution oblige à vérifier la prise en charge des équipements aux deux extrémités, soit 120 vérifications de plus par an à 10 liaisons par mois. Si l'on mélange, on sépare les plages.
• Prendre /31 par défaut alors qu'un équipement ne le prend pas en charge, en laissant seulement ce tronçon en exception /30 à part. Chaque remplacement d'équipement exige une vérification, et un seul oubli rend la liaison inutilisable. On prend /30 par défaut et on découpe les /31 dans la plage des tronçons à prise en charge confirmée.
• Choisir /30 en comptant passer en /31 par la suite. Passer oblige à changer les adresses, ce qui réécrit la configuration et les noms dans la supervision. On décide en partant du principe qu'on ne migrera pas.

Situation

Une entreprise d'environ 100 personnes met en place un sans-fil invité. En temps normal, on compte une vingtaine d'appareils invités, mais les jours de réunions d'information ou d'expositions, 400 arrivent d'un coup. Le trafic vers le réseau d'entreprise est bloqué par des filtres, mais la résolution de noms et l'attribution d'adresses passent par les mêmes équipements que le réseau d'entreprise.

Hypothèses

Le sans-fil invité peut être fourni comme une plage distincte du sans-fil de l'entreprise. Une seule sortie vers l'extérieur peut être prévue pour les invités. Des équipements de résolution de noms et d'attribution d'adresses peuvent être installés à part pour les invités. Il existe un emplacement utilisable dans 172.16/12.

Allocation

Raisonnement

On pense généralement qu'il suffit que le sans-fil invité soit coupé du réseau d'entreprise : on bloque par des filtres le trafic vers le réseau d'entreprise, et c'est réglé. Cela ne suffit pas.

La plage des invités partage aussi des choses avec le réseau d'entreprise en dehors des filtres. Si les invités résolvent les noms avec les équipements de l'entreprise, leurs appareils peuvent interroger les noms des serveurs internes. Même sans réponse, la réaction à la requête révèle quels noms existent. Si les adresses sont attribuées par les mêmes équipements que le réseau d'entreprise, un jour d'événement où 400 appareils arrivent dans une entreprise de 100 personnes, l'attribution d'adresses interne sature elle aussi. Si on fait synchroniser l'heure des invités sur le réseau d'entreprise, il faut ouvrir une route vers le serveur de temps interne.

La plage des invités ne partage donc rien avec le réseau d'entreprise. Elle n'a de route vers aucun segment interne, et sa seule sortie est une sortie unique vers l'extérieur. La résolution de noms et l'attribution d'adresses sont gérées à part, pour les seuls invités. Au lieu de bloquer par des filtres, on fait en sorte que les routes à bloquer n'existent pas du tout. Une route bloquée s'ouvre avec une ligne ; une route qui n'existe pas ne peut pas s'ouvrir.

Le choix des adresses a aussi sa raison. La plupart des appareils invités établissent des connexions vers leur propre entreprise. Si cette entreprise utilise 10/8 en interne et que la plage des invités est aussi dans 10/8, les adresses entrent en collision de l'autre côté et l'invité ne peut plus joindre son entreprise. La plage est prise à un emplacement peu utilisé de 172.16/12.

Marge de croissance

La plage des invités n'a de route vers aucune partie du réseau d'entreprise, et sa seule sortie est une sortie unique vers l'extérieur. La résolution de noms et l'attribution d'adresses sont elles aussi gérées à part pour les invités. Quand les événements amènent plus d'appareils, on ajoute 172.30.4.0/22 pour les accueillir, et ce qui est ajouté sort par la même sortie. Aucune route vers le réseau d'entreprise n'est ajoutée. La plage est prise dans 172.16/12 et ne chevauche pas 10/8, que les entreprises des invités utilisent probablement.

Pièges

• Se contenter de bloquer par des filtres le trafic vers le réseau d'entreprise. Si la résolution de noms ou l'attribution d'adresses sont partagées avec le réseau d'entreprise, des informations internes fuient en dehors des filtres et la charge se propage aussi. On ne partage rien.
• Faire utiliser aux appareils invités la résolution de noms de l'entreprise. Même sans réponse, la réaction aux requêtes révèle quels noms existent. On en prévoit une à part pour les invités.
• Attribuer les adresses des invités avec les mêmes équipements que le réseau d'entreprise. Quand les invités affluent un jour d'événement, l'attribution d'adresses interne sature aussi. On sépare l'attribution d'adresses pour les invités.
• Prendre la plage des invités dans 10/8. Quand un invité se connecte à sa propre entreprise, les adresses entrent en collision avec le réseau interne de celle-ci et la connexion échoue. On la prend à un emplacement peu utilisé de 172.16/12.

Situation

Dans une entreprise d'environ 500 personnes, les équipements placés en DMZ augmentent d'année en année. Un serveur web exposé à Internet, un serveur d'échange de fichiers avec les partenaires commerciaux, des équipements qui reçoivent le courrier de l'extérieur, un serveur qui ne fait qu'appeler des services externes et des équipements qui envoient des alertes de supervision vers l'extérieur cohabitent dans une même plage.

Hypothèses

On peut distinguer les équipements qui reçoivent des connexions initiées depuis l'extérieur de ceux qui ne font que sortir. L'interlocuteur de chaque connexion avec les partenaires commerciaux peut être identifié. Les plages de la DMZ peuvent être fournies séparément par interlocuteur. Le trafic entre plages peut être arrêté à la limite.

Allocation

Raisonnement

Le critère de ce qui va en DMZ est unique : les équipements qui reçoivent des connexions initiées depuis l'extérieur.

Sans critère, tout ce qui parle avec l'extérieur y entre : des équipements qui ne font que sortir de l'intérieur vers l'extérieur, des serveurs qui ne font qu'appeler des services externes, des équipements qui envoient des alertes de supervision vers l'extérieur. Aucun ne reçoit de connexion initiée depuis l'extérieur, il n'y a donc aucune raison de les placer en DMZ. Si on les y place, la DMZ grossit, et quand l'un d'eux est compromis, tout ce qui se trouve à côté devient accessible.

Une fois décidé ce qui y entre, on découpe ensuite selon de qui on reçoit. Ce qui est exposé à Internet et ce qui est dédié aux partenaires commerciaux ne vont pas dans la même plage. N'importe qui peut atteindre ce qui est exposé à Internet, on le conçoit donc en partant du principe qu'il sera compromis. Ce qui est dédié aux partenaires a des interlocuteurs connus, ses autorisations sont donc bien plus étroites. S'ils sont dans la même plage, quand un serveur exposé à Internet est compromis, les fichiers échangés avec les partenaires deviennent accessibles depuis le serveur voisin. Restreindre les interlocuteurs n'a alors plus de sens.

Le trafic entre les plages séparées n'est pas autorisé. Il n'existe aucune raison métier d'aller de ce qui est exposé à Internet vers ce qui est dédié aux partenaires.

Quand apparaît un nouvel équipement qui reçoit depuis l'extérieur et qu'on ne sait pas clairement de qui il reçoit, on le met dans la plage exposée à Internet. Mettre dans la plage des partenaires un équipement dont on ne peut pas restreindre les interlocuteurs fait tomber le principe même de cette plage.

Marge de croissance

La DMZ est découpée selon de qui chaque plage reçoit, et ce qui est exposé à Internet et ce qui est dédié aux partenaires commerciaux vont dans des plages distinctes. Le trafic entre plages n'est pas autorisé. Quand apparaît un nouvel équipement qui reçoit depuis l'extérieur, sa plage est choisie selon de qui il reçoit, et si on ne peut pas le déterminer, il va dans la plage exposée à Internet. Si les plages viennent à manquer, on en découpe dans 10.170.1.0/24. Les équipements qui ne font que sortir n'entrent pas en DMZ, même s'ils se multiplient.

Pièges

• Mettre en DMZ tout ce qui communique avec l'extérieur. Si les équipements qui ne font que sortir y entrent aussi, la DMZ grossit, et une seule compromission atteint tout ce qui est à côté. On n'y place que les équipements qui reçoivent des connexions initiées depuis l'extérieur.
• Mettre ce qui est exposé à Internet et ce qui est dédié aux partenaires commerciaux dans la même plage. Quand la partie exposée est compromise, les fichiers échangés avec les partenaires deviennent accessibles depuis le serveur voisin. On découpe les plages selon de qui on reçoit.
• Autoriser par précaution le trafic entre les plages séparées. Une autorisation sans raison métier ne sert que de passage à un intrus. On n'autorise rien entre les plages.
• Mettre dans la plage des partenaires un équipement dont l'interlocuteur n'est pas clair. Cette plage restreint ses autorisations en partant du principe que les interlocuteurs sont connus, et ce principe tombe. Dans le doute, on le met dans la plage exposée à Internet.

Situation

Dans un réseau virtuel du cloud, on crée dans chaque zone de défaillance un petit sous-réseau pour 10 équipements. Par habitude du réseau d'entreprise, on pense qu'un /28 permettra d'en placer 14. Un sous-réseau applicatif d'environ 200 équipements est aussi prévu dans le même réseau virtuel.

Hypothèses

On sait que le fournisseur utilisé prend d'avance quelques adresses dans chaque sous-réseau. On peut vérifier combien il en prend et quelle est la taille minimale autorisée. La taille d'un sous-réseau ne peut plus être modifiée après sa création. Il reste de la place dans le réseau virtuel.

Allocation

Raisonnement

Quand on crée un sous-réseau dans le cloud, le fournisseur en prend d'avance quelques adresses. Cela varie selon le fournisseur, mais il est courant qu'il prenne les quatre premières et la dernière, cinq au total. Sur un réseau d'entreprise, seules la première et la dernière adresse sont inutilisables ; si l'on découpe sans connaître cette différence, on se retrouve à court d'adresses.

La différence pèse surtout sur les petits sous-réseaux. Dans un /24, c'est 5 sur 256, moins de 2 pour cent. Dans un /26, 5 sur 64, soit 8 pour cent. Dans un /28, la plus petite taille possible, 5 sur 16 disparaissent, environ 30 pour cent. Il n'en reste que 11 utilisables.

Si l'on découpe un /28 comme sur le réseau d'entreprise, on prévoit 14 équipements mais on ne peut en placer que 11. Avec 10 équipements, la marge n'est que d'une adresse, et le jour où l'on en ajoute deux, le sous-réseau déborde. Comme sa taille ne peut plus changer après la création, un débordement oblige à le recréer.

Quand on découpe de petits sous-réseaux, on compare donc le nombre d'équipements avec ce qui reste après les réservations. Pour 10 équipements, un /28 ne suffit pas : on prend un /27 à la place. Un /27 laisse 27 adresses utilisables une fois 5 retirées sur 32. Plus le sous-réseau est petit, plus la part perdue est grande : en règle générale, les petits sous-réseaux se découpent un cran plus grand que sur le réseau d'entreprise.

Le nombre d'adresses réservées varie selon le fournisseur, tout comme la taille minimale. En choisissant un profil de réservation dans l'onglet Calculer, on obtient aussitôt le nombre d'adresses utilisables. C'est là qu'on vérifie les estimations.

Marge de croissance

Pour les petits sous-réseaux, on retire les 5 adresses réservées avant de comparer avec le nombre d'équipements. Pour 10 équipements, un /28 ne suffit pas : on prend un /27 à la place. On les aligne à la même taille, un par zone de défaillance. Quand il faut davantage de sous-réseaux, on les découpe dans 10.216.2.0/24. En cas de doute sur une estimation, on choisit le profil de réservation dans l'onglet Calculer pour vérifier le nombre d'adresses utilisables.

Pièges

• Compter les adresses utilisables comme sur le réseau d'entreprise. En ne retirant que la première et la dernière, on oublie les trois autres que prend le fournisseur, et le nombre d'équipements prévu n'y tient pas. Comparer avec le nombre restant après les réservations.
• Faire de la plus petite taille, le /28, la norme. 5 adresses sur 16 disparaissent, il n'en reste que 11, et quelques équipements de plus suffisent à le faire déborder. Pour une dizaine d'équipements, prendre un /27 à la place.
• Penser qu'un sous-réseau pourra être agrandi plus tard. Sa taille ne change plus après la création, et un débordement oblige à le recréer. Estimer dès le départ en incluant les réservations.
• Croire que tous les fournisseurs réservent le même nombre d'adresses. Le nombre d'adresses prises et la taille minimale varient selon le fournisseur. Vérifier avec le profil du fournisseur utilisé.

Situation

On relie le réseau d'une entreprise acquise à son propre réseau. Les deux utilisent 10/8, et de nombreuses plages se chevauchent. Pour des raisons métier, les réseaux doivent être reliés le mois prochain, et on n'a pas le temps de renuméroter l'un ou l'autre côté. Il est proposé de les relier en traduisant les adresses à la limite.

Hypothèses

On peut placer, entre les réseaux des deux entreprises, une seule limite capable de traduire les adresses. Les adresses traduites peuvent être prises dans un espace qui n'appartient à aucune des deux. On peut inscrire une échéance dans les règles de traduction. Le côté à renuméroter peut être décidé sans attendre une décision de la direction.

Allocation

Raisonnement

Il existe deux façons de relier deux réseaux qui se chevauchent : renuméroter l'un des deux, ou traduire les adresses à la limite. La traduction se met en place en une nuit ; la renumérotation prend des mois. Choisir la traduction au début d'une intégration est juste.

Le problème, c'est que la traduction devient permanente. Comme le trafic passe grâce à elle, la raison de renuméroter disparaît. Trois ans plus tard, les règles de traduction se sont accumulées et personne ne sait plus expliquer l'ensemble. À chaque incident, il faut vérifier si une adresse vue dans les journaux est antérieure ou postérieure à la traduction.

C'est pourquoi, le jour où la traduction est mise en place, on décide deux choses en même temps : l'échéance et le côté qui sera renuméroté. L'échéance est fixée sous forme de date et inscrite dans les règles de traduction elles-mêmes. Le côté à renuméroter est décidé le jour même, et la période de traduction est traitée comme un temps de préparation de la renumérotation. Une traduction pour laquelle on n'a pas décidé quel côté renuméroter ne peut qu'être prolongée quand l'échéance arrive.

Les adresses traduites sont prises dans un espace qui n'appartient à aucun des deux côtés. Si les deux entreprises utilisent 10/8 et se chevauchent là, les adresses traduites sont prises dans 172.16/12. Si l'on utilise l'espace libre du 10/8 de l'un des deux côtés, la prochaine entreprise accueillie créera de nouveau un chevauchement.

Certaines traductions peuvent être permanentes. Lorsque la conception suppose que les mêmes adresses se répètent côte à côte, comme pour des lignes de production construites en copiant la même configuration, une traduction permanente est correcte. Le chevauchement lors d'une intégration n'est pas une hypothèse de conception mais un accident, et le remède à un accident ne doit pas devenir permanent.

Marge de croissance

Les plages traduites sont prises à l'intérieur de 172.16/12, et on sépare la plage servant à voir le réseau de l'autre entreprise de celle qui présente son propre réseau à l'autre entreprise. L'échéance est inscrite dans les règles de traduction, et d'ici l'échéance on renumérote le côté décidé le jour de la mise en place de la traduction. La croissance d'ici l'échéance est découpée dans 172.18.24.0/22. Une traduction échue n'est pas prolongée ; si une prolongation est nécessaire, on repart de la décision sur le côté à renuméroter.

Pièges

• Ne pas fixer d'échéance au moment de mettre en place la traduction. Le trafic passe, donc la raison de renuméroter disparaît, et les règles de traduction s'accumulent jusqu'à ce que personne ne sache plus les expliquer.
• Mettre en place la traduction sans décider quel côté renuméroter. À l'échéance, la discussion repart de la question du côté à déplacer, et il ne reste qu'à prolonger. On décide le même jour que la traduction.
• Prendre les adresses traduites dans l'espace libre de son propre 10/8. La prochaine fois qu'une autre entreprise est accueillie, elles se chevauchent de nouveau. On les prend dans un espace qui n'appartient à aucun des deux côtés.
• Écrire les règles de traduction hôte par hôte. Les échéances doivent alors elles aussi être gérées hôte par hôte, et personne ne sait quelles règles restent. On les écrit par plage.

Situation

Une usine compte plusieurs lignes de production de même configuration d'équipements et prévoit d'en ajouter. Les automates livrés par le fournisseur d'équipement ont des adresses IP fixes gravées d'usine, et l'on part d'une situation où les mêmes adresses se retrouvent sur plusieurs lignes.

Hypothèses

Les adresses des automates de chaque ligne ne peuvent pas être modifiées, ou leur modification impose une nouvelle réception par le fournisseur d'équipement. Les lignes n'ont pas besoin de communiquer directement entre elles ; elles communiquent seulement avec les systèmes de collecte de niveau supérieur. Un équipement de niveau 3 ou un équipement capable de faire du NAT peut être placé à la limite de chaque ligne.

Allocation

Raisonnement

Ce qui distingue fondamentalement un réseau OT de l'informatique, c'est qu'on ne choisit pas librement les adresses. Les fournisseurs d'équipement livrent la même configuration à de nombreux clients : les adresses des automates sont donc fixées en usine, et la même 192.168.0.10 existe aussi bien sur la ligne 2 que sur la ligne 3. Si l'on applique le réflexe informatique habituel, « elles se chevauchent, il faut renuméroter », la discussion porte aussitôt sur la garantie des équipements et une nouvelle réception, et l'atelier s'arrête.

On ne renumérote donc pas. Les adresses à l'intérieur de la ligne restent telles que le fournisseur d'équipement les a configurées ; l'équipement situé à la limite de la ligne applique une traduction d'adresses 1:1, et seules les adresses vues de l'extérieur sont distinguées par numéro de ligne. Un automate de la ligne 1 apparaît de l'extérieur comme 172.20.1.x, le même équipement de la ligne 2 comme 172.20.2.x. Avec la règle « troisième octet = numéro de ligne », quiconque lit les journaux du système de collecte reconnaît la ligne immédiatement, sans connaître le nom de l'équipement.

L'essentiel de cette conception est de séparer les contraintes du fournisseur d'équipement et la maîtrise par l'informatique au moyen d'une seule couche : la traduction. L'intérieur de la ligne relève du fournisseur d'équipement ; à partir de la limite, c'est le domaine du service informatique. Le principal avantage est qu'ajouter une ligne n'oblige pas à refaire la conception : on incrémente le numéro et l'on copie la même configuration.

Marge de croissance

Pour les prochaines extensions, 172.20.4.0/22 (lignes 4 à 7) est réservé. Comme le bloc de base est un /16, la règle qui fait du troisième octet le numéro de ligne va jusqu'à la ligne 255 (le 0 n'est pas utilisé comme numéro de ligne et sert à la collecte et à la maintenance communes), et à partir de la ligne 8 on continue naturellement avec 172.20.8.0/21 puis 172.20.16.0/20. Si des usines s'ajoutent, le deuxième octet devient le numéro d'usine : 172.21.0.0/16 est attribué à l'usine suivante, et les deux sont agrégées en 172.20.0.0/15. Une ligne ne devient trop grande pour son /24 que lorsqu'elle dépasse 250 automates, et à cette échelle il est plus simple de l'exploiter en la découpant logiquement.

Pièges

• Autoriser les échanges entre lignes « au cas où ». Lorsqu'une ligne est infectée par un logiciel malveillant, toutes les lignes de même configuration s'arrêtent en même temps. On bloque par défaut le trafic entre lignes et l'on fait passer le trafic nécessaire par les systèmes de collecte.
• Ne pas prévoir de segment pour les postes de maintenance et brancher directement les PC apportés sur le segment de contrôle. C'est la porte d'entrée la plus fréquente des incidents OT, et elle ne laisse aucune trace. On crée un segment dédié, et c'est uniquement depuis celui-ci qu'on accède au côté contrôle.
• Ne conserver la table de correspondance de la traduction d'adresses que dans la configuration de l'équipement. Quand la personne qui l'a configurée change de poste, plus personne ne peut dire quelle adresse externe correspond à quel équipement. La table de correspondance est tenue dans les documents de conception comme source de référence.
• Utiliser la plage 192.168 pour les adresses de l'usine. Elle entre facilement en conflit avec les routeurs et routeurs mobiles qu'apportent les prestataires de maintenance, et le conflit ne se révèle que sur place. On découpe les adresses dans 172.16/12 ou 10/8.
• Associer numéros de ligne et adresses en reprenant, à chaque extension, le premier numéro libre. Lorsque la ligne 7 est démontée et que d'autres équipements prennent ensuite sa place, numéros et lignes réelles ne correspondent plus, et plus personne ne s'y fie. Les numéros ne sont jamais réutilisés.

Situation

Une usine d'environ 300 employés, avec un bâtiment de bureaux et un bâtiment de production sur le même site, exploités jusqu'ici comme un seul réseau. Il faudra toujours envoyer des instructions aux équipements depuis la gestion de production et collecter leurs résultats, mais on veut mettre fin à la situation où les PC de bureau atteignent directement les automates. À ce stade, on ne touche pas à la conception interne des lignes et l'on redessine d'abord uniquement les limites situées au-dessus et au-dessous d'elles.

Hypothèses

Au moins un équipement de niveau 3 peut être placé entre le côté bureaux et le côté usine. Les flux qui traversent les deux côtés peuvent être inventoriés, au minimum par serveur d'interconnexion, avec leur interlocuteur et leur sens. Les adresses des automates ne changent pas cette fois-ci ; la refonte interne des lignes se fait séparément. Les exigences incluent que la production puisse continuer pendant que les équipements de la limite sont hors service.

Allocation

Raisonnement

Personne ne s'oppose à la séparation. Ce qui ne se décide pas, c'est la taille de la zone placée à la limite.

Prendre un /24 pour la limite échoue toujours. À cette échelle, les seules machines qui ont vraiment besoin de communiquer avec les deux côtés sont les serveurs d'interconnexion, une bonne douzaine. Les plus de 240 adresses restantes deviennent des terrains vagues, et les terrains vagues finissent toujours par être occupés. Six mois plus tard arrive un serveur de fichiers de l'informatique de gestion ; l'année suivante, un serveur de rebond joint à l'infrastructure d'authentification des bureaux. À ce moment, la limite n'en est plus une, mais rien ne change dans le tableau d'adresses, donc personne ne s'en aperçoit.

C'est pourquoi l'interconnexion s'en tient à un /28, pas davantage. Avec seulement 14 adresses, quiconque veut placer une quinzième machine doit d'abord en parler à quelqu'un. Le but est que la taille joue le rôle d'une règle d'exploitation. La marge de croissance est placée à côté, sous un autre nom, pour la phase 2, et la zone d'interconnexion elle-même n'est jamais élargie.

Le découpage du /20 en trois domaines, 0 à 3 (informatique), 4 à 7 (limite) et 8 à 15 (contrôle), est lui aussi voulu. Les filtres de l'équipement de limite s'écrivent en trois lignes, 10.60.0.0/22, 10.60.4.0/22 et 10.60.8.0/21, et ces trois lignes ne changent pas quand on ajoute des segments. Une conception qui oblige à toucher aux filtres à chaque ajout finira un jour par une erreur qui arrête la production.

La zone des services partagés du réseau de contrôle, un /25, est placée côté contrôle pour la disponibilité. La production continue pendant que les équipements de la limite sont hors service. Si la synchronisation horaire et la résolution de noms dépendent du côté bureaux, un arrêt de la limite devient un arrêt du côté contrôle.

Marge de croissance

À la limite, 10.60.4.64/26 est laissé libre pour la phase 2. Il ne sert pas à élargir l'interconnexion, mais à ajouter plus tard des échanges de données avec l'extérieur et des relais de maintenance à distance. Côté contrôle, 10.60.12.0/22 est laissé libre pour les zones par ligne, et la conception de chaque ligne s'y place. Si le sans-fil devient trop grand pour son /24, on ajoute 10.60.10.0/23. Si des usines s'ajoutent, 10.60.16.0/20 est attribué à l'usine suivante, et l'ensemble est agrégé en 10.60.0.0/16. Comme les bornes des trois domaines sont alignées sur des limites de /22, les trois lignes de filtre ont la même forme dans toutes les usines.

Pièges

• Placer un serveur de rebond à la limite et le joindre à l'infrastructure d'authentification des bureaux. Cela ouvre un chemin par lequel les identifiants arrivent du côté bureaux, et la limite perd son sens. Si l'on place un serveur de rebond, son authentification reste confinée à l'intérieur de la limite.
• Laisser les automates se synchroniser sur un serveur côté bureaux. Dès que l'équipement de limite est arrêté, l'heure côté contrôle commence à dériver, et l'on ne peut plus rapprocher les journaux lors de l'analyse d'une panne. On place la synchronisation horaire côté contrôle.
• Définir l'exigence de séparation uniquement comme « pas d'accès des bureaux au réseau de contrôle ». Les flux du côté contrôle vers les bureaux restent incontrôlés, et un appareil glissé parmi les équipements garde une voie de sortie. On fixe les règles dans les deux sens.
• Confier aussi la collecte et le stockage de fichiers aux serveurs d'interconnexion. Les contraintes du côté qu'on ne peut pas arrêter empêchent leur mise à jour, et en quelques années plus personne n'ose y toucher. On les sépare par rôle et l'on maintient leur nombre dans les limites du /28 attribué.

Situation

Une entreprise de 10 sites a reçu de son opérateur un /48 IPv6. Jusqu'ici, en IPv4, elle ajustait la taille de chaque sous-réseau au nombre d'appareils et veillait à l'emplacement des réserves et à la fragmentation. Elle s'apprête à commencer l'attribution IPv6 dans le même état d'esprit.

Hypothèses

Un /48 a été reçu de l'opérateur. Les équipements de l'entreprise peuvent utiliser la configuration automatique des adresses IPv6. Le nombre de sites et le nombre d'usages devraient rester chacun inférieurs ou égaux à 15. Les adresses sont destinées à être lues par des personnes qui en tirent un sens.

Allocation

Raisonnement

Un /48 contient 65 536 sous-réseaux /64 au total. Une grande partie de ce que l'on a accumulé avec IPv4 s'inverse ici.

En IPv4, la taille d'un sous-réseau se décidait selon le nombre d'appareils : un /28 pour 10, un /24 pour 200. En IPv6, on ne fait pas ainsi. Chaque sous-réseau est toujours un /64, quel que soit le nombre d'appareils. Le mécanisme par lequel les appareils choisissent eux-mêmes leur adresse repose sur un préfixe /64 par sous-réseau. Si l'on découpe plus petit qu'un /64, ce mécanisme cesse de fonctionner.

Il n'y a pas non plus à économiser. Presque aucune organisation n'épuisera 65 536 sous-réseaux /64 au total. Les problèmes qui ont tant coûté en IPv4, comme l'emplacement des réserves ou la prévention de la fragmentation, disparaissent presque entièrement.

Il reste une seule décision : comment découper les 16 bits du quatrième groupe de 16 bits. Ici, on attribue 4 bits au site, 4 bits à l'usage et 8 bits à un numéro séquentiel. Lorsque les frontières de sens tombent sur les frontières entre chiffres hexadécimaux, une adresse se lit d'un coup d'œil. 2001:db8:100:1200::/64, par exemple, est le premier sous-réseau de serveurs du site 1.

Le découpage s'aligne sur les chiffres hexadécimaux. Si l'on découpe au milieu d'un chiffre, chaque lecture d'une adresse oblige à la convertir en binaire, et l'avantage de la lisibilité disparaît. Si le nombre de sites risque de dépasser 15, on attribue dès le départ 8 bits au site et 4 bits chacun à l'usage et au numéro séquentiel.

Marge de croissance

Le premier chiffre hexadécimal du quatrième groupe de 16 bits est le site, numéroté à partir de 1, le 0 étant réservé aux besoins communs à toute l'entreprise. Le deuxième chiffre est l'usage et les deux derniers le numéro séquentiel. Les sous-réseaux sont toujours des /64 et ne grandissent pas quand les appareils augmentent. Si les /64 du tableau des segments paraissent grands par rapport au nombre d'appareils, c'est que le protocole exige un préfixe /64, et non qu'on a pris de la marge. Si les sites dépassent 15, on garde le même découpage et l'on obtient un deuxième /48 de l'opérateur.

Pièges

• Dimensionner les sous-réseaux selon le nombre d'appareils et découper plus petit qu'un /64 complet. Le mécanisme par lequel les appareils choisissent eux-mêmes leur adresse suppose un préfixe /64 et cesse de fonctionner. Les sous-réseaux sont toujours des /64 complets.
• Découper serré par souci des réserves et de la fragmentation, comme en IPv4. Épuiser 65 536 sous-réseaux /64 n'arrive pratiquement jamais, et serrer n'apporte rien. On donne la priorité à la lisibilité.
• Découper le quatrième groupe de 16 bits au milieu d'un chiffre hexadécimal. Chaque lecture d'une adresse oblige à la convertir en binaire, et l'on ne peut plus lire de sens dans l'adresse. On découpe aux frontières des chiffres hexadécimaux.
• Numéroter le chiffre du site à partir de 0. Il ne reste plus de place pour les besoins communs à toute l'entreprise, qu'il faut ensuite caser de force. Le 0 est réservé aux besoins communs à toute l'entreprise.