Comprendre la notation CIDR et les plages d'adresses IP

La notation CIDR s’écrit sous la forme address/prefix, où le préfixe correspond au nombre de bits de tête fixés comme partie réseau — ainsi, dans 10.0.0.0/16, les 16 premiers bits identifient le réseau et les 16 restants sont disponibles pour les hôtes.

La plupart des gens l’apprennent à la dure, vers la troisième fois qu’un security group bloque silencieusement le trafic et que le coupable s’avère être un préfixe erroné d’un seul chiffre. Cette unique ligne représente l’essentiel de ce dont vous avez besoin pour arrêter de copier-coller 10.0.0.0/16 dans un fichier Terraform et commencer à le lire vraiment. Cet article vous donne le modèle mental, le calcul en deux étapes pour passer d’un préfixe à une plage utilisable et à un nombre d’hôtes, ainsi que les contextes dans lesquels un développeur web ou full-stack rencontre concrètement le CIDR (dimensionnement de VPC, règles de security group, listes d’autorisation et réseaux de conteneurs), y compris les pièges qui cassent discrètement la connectivité.

Qu’est-ce que la notation CIDR ?

La notation CIDR (Classless Inter-Domain Routing) exprime un réseau sous la forme d’une adresse IP suivie d’une barre oblique et d’une longueur de préfixe, cette longueur correspondant au nombre de bits de tête fixés comme partie réseau. Elle a remplacé le système rigide des classes A/B/C, afin que les blocs puissent avoir n’importe quelle taille au lieu de s’aligner sur des frontières de 8, 16 ou 24 bits. Le mécanisme a été introduit en 1993 par la RFC 1519 puis consolidé dans la référence actuelle, la RFC 4632, en 2006. Le préfixe n’est pas le nombre total de bits de l’adresse, une confusion fréquente. Dans 192.168.129.23/17, le /17 signifie que les 17 premiers bits sont des bits réseau, laissant 15 bits pour les hôtes.

Le modèle binaire : bits réseau et bits hôte

Une adresse IPv4 est un nombre de 32 bits découpé en quatre octets de 8 bits, et le préfixe /n trace une ligne à travers ces 32 bits : tout ce qui se trouve à gauche de la ligne est la partie réseau fixe, tout ce qui se trouve à droite est la partie hôte variable. Déplacez la ligne vers la droite (préfixe plus grand) et vous obtenez davantage de réseaux, plus petits ; déplacez-la vers la gauche et vous obtenez moins de réseaux, plus grands.

Prenons 10.0.1.0/24. Le /24 coupe après le troisième octet : les 24 premiers bits sont verrouillés et les 8 derniers vous appartiennent :

00001010 . 00000000 . 00000001 . 00000000
└──────── network (24 bits) ──────┘ └ host ┘
   10          0          1        0–255

Ces 8 bits d’hôte vont de 00000000 à 11111111 : 256 combinaisons, soit de 10.0.1.0 à 10.0.1.255. Le préfixe est le seul élément qui détermine où tombe la coupure.

Combien d’hôtes contient un bloc CIDR ?

Le nombre d’hôtes utilisables dans un bloc IPv4 est 2^(32 − prefix) − 2 : un /24 en donne 254, un /26 en donne 62 et un /30 en donne 2 ; les deux adresses soustraites sont l’adresse de réseau (tous les bits d’hôte à 0) et l’adresse de diffusion (tous les bits d’hôte à 1), qui ne peuvent être affectées à aucun hôte. Calculez d’abord le total des adresses (2^(32 − prefix)), puis soustrayez deux.

Deux exceptions à la règle du −2 comptent en pratique : un /31 fournit 2 adresses utilisables car la RFC 3021 supprime la réservation des adresses de réseau et de diffusion sur les liaisons point à point, et un /32 désigne une route vers un hôte unique, la forme utilisée pour nommer une IP précise dans un pare-feu ou une règle de liste d’autorisation.

Lire un bloc CIDR sur le terrain

Pour lire un bloc comme 10.0.1.0/24 : l’adresse de réseau est 10.0.1.0, l’adresse de diffusion est 10.0.1.255 et la plage utilisable va de 10.0.1.1 à 10.0.1.254. La recette tient en quatre étapes : (1) le préfixe indique combien de bits sont fixés ; (2) mettez les bits d’hôte restants à 0 pour obtenir l’adresse de réseau ; (3) mettez-les à 1 pour l’adresse de diffusion ; (4) tout ce qui se trouve entre les deux est utilisable.

Pour raisonner dans l’autre sens, en partant d’un besoin en hôtes pour arriver à un préfixe, choisissez le plus petit bloc dont le nombre d’adresses utilisables couvre votre besoin. Besoin de place pour 30 équipements ? Un /27 offre 30 adresses utilisables ; un /28 n’en offre que 14, donc /27 est la réponse. Vous pouvez vérifier n’importe quel bloc avec le module ipaddress de la bibliothèque standard Python, sans rien installer :

python3 -c "import ipaddress; n=ipaddress.ip_network('10.0.1.0/24'); print(n.network_address, n.broadcast_address, n.num_addresses)"
# 10.0.1.0 10.0.1.255 256

Exécutez-le sur n’importe quel bloc pour valider votre calcul mental avant de l’inscrire dans une configuration.

Si vous préférez éviter le terminal, le calculateur CIDR d’OpenReplay effectue la même décomposition dans le navigateur. Collez un bloc comme 10.0.0.0/16 et il renvoie les adresses de réseau et de diffusion, le masque réseau et le masque générique (wildcard), le premier et le dernier hôte utilisable, ainsi que le nombre total d’adresses. Il prend en charge IPv4 et IPv6 et utilise de l’arithmétique en grands entiers, de sorte que les blocs volumineux et les plages IPv6 sont renvoyés de manière exacte. Tout est calculé localement : vos plages internes ne quittent jamais votre machine.

Où les développeurs rencontrent réellement le CIDR

La plupart des développeurs croisent le CIDR dans la configuration cloud et applicative bien avant de le rencontrer dans une table de routage. La RFC 1918 réserve trois plages privées que vous verrez sans cesse (10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16), dont aucune n’est routable sur l’Internet public, ce qui explique pourquoi les VPC cloud et les réseaux Docker y puisent leurs adresses. Quatre cas d’usage couvrent presque tout ce que vous manipulerez :

• Dimensionnement des VPC et des sous-réseaux. Vous définissez un bloc à la création, puis y découpez des sous-réseaux. Le bloc IPv4 d’un VPC AWS doit être compris entre /16 et /28, et chaque sous-réseau réserve les quatre premières adresses ainsi que la dernière (cinq, et non deux) : un sous-réseau /24 fournit donc 251 adresses utilisables sur AWS, et non 254. La règle générique du −2 constitue un plafond, pas une garantie.
• Règles de pare-feu et de security group. Les règles sont délimitées par un CIDR, par exemple autoriser le trafic entrant sur 5432 uniquement depuis 10.10.1.0/24, afin qu’un tier base de données accepte le trafic Postgres provenant du tier web et de rien d’autre.
• Listes d’autorisation et de refus dans la configuration applicative. Les origines CORS, les règles WAF, les plages sources d’API Gateway et les directives allow/deny de nginx acceptent toutes des blocs CIDR. Un préfixe trop restrictif bloque silencieusement des clients légitimes ; les session replays de ces implémentations font fréquemment apparaître la défaillance sous forme de requêtes bloquées ou en échec, dont l’origine se ramène à un unique préfixe erroné.
• Le piège du chevauchement de CIDR. Deux réseaux que vous souhaitez appairer ou relier par VPN ne doivent pas utiliser de blocs CIDR qui se chevauchent, car un hôte ne peut pas disposer de deux routes non ambiguës vers la même adresse. Attribuez à chacun sa propre plage RFC 1918 sans chevauchement, par exemple 10.10.0.0/16 et 10.20.0.0/16.

Une valeur mérite d’être mémorisée : 0.0.0.0/0 en IPv4 (et ::/0 en IPv6) signifie toutes les adresses. C’est utile pour une route par défaut, mais c’est une arme braquée sur son pied en tant que règle d’autorisation entrante : 0.0.0.0/0 sur le port 22 ou 5432 revient à ouvrir la porte à l’Internet tout entier.

IPv6 utilise la même notation

IPv6 applique une notation avec barre oblique identique à des adresses de 128 bits, et le /64 constitue la taille standard par sous-réseau, laissant 64 bits pour les hôtes de chaque sous-réseau. Considérez le /64 comme une convention, non comme une loi : ce n’est pas un invariant universel, et AWS lui-même autorise des masques de sous-réseau IPv6 de /44 à /64 par incréments de /4. La logique de découpage binaire est exactement la même. Seule l’adresse est plus longue.

Lisez le préfixe comme un nombre de bits réseau, appliquez 2^(32 − prefix) − 2 pour les hôtes IPv4 utilisables, gardez en mémoire les exceptions du /31, du /32 et des réservations propres au cloud, et veillez à ce que les réseaux appairés ne se chevauchent pas. Faites cela et vous pourrez dimensionner un sous-réseau ou auditer une règle de pare-feu sans recourir à une calculatrice. La prochaine fois qu’un bloc CIDR apparaîtra dans une pull request, décodez-le à vue et vérifiez si ce /0 était bien censé s’y trouver.

FAQ

Quelle est la différence entre un masque de sous-réseau comme 255.255.255.0 et un préfixe CIDR comme /24 ?

Ils expriment la même frontière de deux façons différentes. Un masque de sous-réseau est une valeur de 32 bits où les bits réseau valent 1 et les bits hôte valent 0 : 255.255.255.0 correspond donc, en binaire, à 24 uns suivis de 8 zéros. Le préfixe CIDR /24 se contente de compter ces bits à 1 en tête. 255.255.255.0 équivaut à /24, 255.255.255.192 équivaut à /26 et 255.255.255.252 équivaut à /30. Le CIDR est la notation abrégée du même masque.

Combien d'adresses IP utilisables un /30 fournit-il, et pourquoi est-il courant pour les liaisons point à point ?

Un /30 fournit 2 adresses utilisables sur 4 au total, car les adresses de réseau et de diffusion restent réservées selon la règle standard du moins deux. Deux adresses utilisables suffisent exactement aux deux extrémités d'une liaison point à point, ce qui explique pourquoi le /30 en était le choix traditionnel. La RFC 3021 a ensuite autorisé le /31 à remplir le même rôle avec 2 adresses utilisables sur 2, en supprimant la réservation des adresses de réseau et de diffusion et sans gaspiller aucune adresse.

Deux sous-réseaux peuvent-ils avoir des blocs CIDR qui se chevauchent au sein du même réseau ?

Pas s'ils doivent router du trafic l'un vers l'autre. Au sein d'une même table de routage, un chevauchement est résolu par correspondance du préfixe le plus long : un paquet destiné à 10.0.1.5 suit la route 10.0.1.0/24 plutôt que la route plus large 10.0.0.0/16, si bien que le chemin n'est jamais ambigu. Le problème surgit lorsque vous connectez deux réseaux adressés indépendamment. Une connexion de peering entre deux VPC utilisant tous deux 10.0.0.0/16 échoue, car chaque côté route déjà ce bloc localement et n'a aucun moyen d'atteindre l'autre. C'est la raison pour laquelle le peering de VPC et les VPN site à site exigent des plages sans chevauchement. Attribuez dès le départ à chaque réseau son propre bloc RFC 1918 distinct.

Un numéro de préfixe plus petit signifie-t-il un réseau plus grand ou plus petit ?

Un numéro de préfixe plus petit signifie un réseau plus grand. Le préfixe compte les bits réseau fixés : moins de bits réseau laissent donc davantage de bits hôte libres. Un /8 dispose de 24 bits d'hôte et de plus de 16 millions d'adresses, tandis qu'un /24 dispose de 8 bits d'hôte et de 256 adresses. À mesure que le numéro de préfixe diminue, la taille du bloc double à chaque étape : un /23 contient deux fois plus d'adresses qu'un /24, et un /16 en contient 256 fois plus qu'un /24.

Pourquoi AWS n'accorde-t-il que 251 adresses utilisables à un sous-réseau /24 au lieu de 254 ?

AWS réserve cinq adresses par sous-réseau, et non les deux que suppose la règle générique du moins deux. AWS met de côté les quatre premières adresses de chaque bloc CIDR de sous-réseau ainsi que la dernière, pour l'adresse de réseau, le routeur du VPC, le DNS, un usage futur et la diffusion. Un /24 comptant 256 adresses au total fournit donc 251 adresses utilisables sur AWS, contre 254 dans un calcul réseau classique. Vérifiez toujours les règles de réservation de votre fournisseur cloud avant de dimensionner un sous-réseau au plus juste.