FAQ RéseauxConsultez toutes les FAQ

Il existe principalement deux méthodes pour affecter une adresse IP (et une configuration) à une interface réseau.

• Configuration manuelle ou fixe : L'utilisateur paramètre lui-même les diverses informations de l'interface réseau comme l'adresse IP, la passerelle, les DNS.
• Configuration automatique ou dynamique : Dans ce cas aucune information n'est fournie à l'interface, elle doit se débrouiller seule. Elle interroge donc sur le réseau un service spécifique dit serveur DHCP pour obtenir la configuration en vigueur sur ce réseau avec une adresse IP non déjà utilisée.
  

C'est ce que l'on appelle la notation CIDR (pour Classless InterDomain Routing).

C'est une "nouvelle" façon d'exprimer une adresse IP et son masque de sous-réseau.
C'est la seule notation qui devrait théoriquement être utilisé désormais (mais l'ancienne fait de la résistance encore ), cette notation est utilisée aussi bien en IPv4 qu'en IPv6

le /xx signifie "les xx bits de poids fort, c'est à dire les plus à gauche correspondent à la partie réseau de l'adresse IP" sous-entendu les bits restant, à savoir (32-xx, dans le cas d'une IPv4, 128-xx dans le cas d'une IPv6) indique la partie host de l'adresse IP.

Si l'on traduit cela en masque, ça dit que les 24 premiers bits du masque en partant de la gauche sont à 1 les autres à 0. Pour une adresse IPv4, ça donne un masque de 255.255.255.0

Donc 192.168.10.241/24 est équivalent à 192.168.10.241 masque : 255.255.255.0

Ainsi un /24 donne un masque de 255.255.255.0
un /16 donne un masque de 255.255.0.0
un /29 donne un masque de 255.255.255.248
.....

Par exemple, nous avons cette plage d'adresse, mais aucune information de masque réseau : 10.1.64.1 --> 10.1.127.254
Comment allons-nous calculer ce masque réseau ?

On sait qu'une adresse internet seule ne représente rien. Elle doit toujours être associée à un masque de (sous-)réseau pour être interprétable. Le rôle de ce masque de réseau est d'indiquer dans une adresse IP quelconque qu'elle est la partie de l'adresse qui identifie un réseau (Network), qu'elle est la partie qui identifie une machine dans ce réseau(Host).

2 méthodes :
La méthode complète :
On commence par convertir les adresses en binaire
10.1.64.1 --> 00001010.00000001.01000000.00000001
10.1.127.254 --> 00001010.00000001.01111111.11111110

En partant de la gauche, on regarde plus grand groupe de bits communs aux 2 adresses.
00001010.00000001.01000000.00000001
00001010.00000001.01111111.11111110
Pour ce groupe de bits en commun, on met les bits du masque correspond à 1, les autres à 0
11111111.11111111.11000000.00000000
On obtient ainsi le plus petit masque possible pour que ces adresses soit dans le même réseau logique, soit ici 255.255.192.0 (une fois reconvertis en décimal)

A partir de ce masque là, on détermine 2 adresses importantes
- L'adresse réseau (tous les bits du host à 0) --> 00001010.00000001.01000000.00000000 soit 10.1.64.0
- L'adresse Broadcast (tous les bits du host à 1) --> 00001010.00000001.01111111.11111111 soit 10.1.127.255
Ces 2 adresses là ne pouvant pas être utilisées pour des machines, cela fait 16384 adresses pour 16382 machines adressables

Une méthode plus rapide
En analysant les 2 adresses, on constate que
- Les 2 premiers octets (10.1.) sont strictement identiques, ils appartiennent donc à la partie Network (donc bits à 1 dans le masque)
- Le 3ème octet diffère (.64. et .127.), on en déduit donc sans autre réflexion que le 4ème octet ne peut être que dans la partie Host (donc bits à 0 dans le masque)
A ce point là, juste d'un coup d'oeil (une fois exercé) on a déjà déduit le masque 255.255.???.0
Reste le 3ème octet que l'on analyse selon la méthode précédente (mais sur un seul octet au lieu de 4, ce qui est quand même plus rapide)

NOTA : Notation CIDR :
La notation @IP et masque est une méthode de notation un peu ancienne, méthode qui devient très lourde en IPV6. Désormais on utilise plutôt la notation CIDR. En notation CIDR, au lieu d'indiquer le masque sous la forme de 4 octets comme l'adresse IP, on fait juste succéder l'adresse IP du nombre de bits à 1 dans le masque de réseau.
Ici, avec le masque 255.255.192.0, on a 18 bits à 1. En notation CIDR on écrira donc 10.1.64.0/18

Initialement, l'internet, basé sur l'IPv4 a été découpé en classes d'adresse. Un réseau est désigné par un couple d'une adresse IP et de son masque de réseau. Les classes définissent les différents masques possibles, soit 255.0.0.0 pour une classe A, 255.255.0.0 pour une classe B, 255.255.255.0 pour une classe C. Le routage se fait donc par réseau, donc par couple adresse et masque.

Dès le début des années 1990, avec le développement et l’expansion d'internet, on s'aperçoit assez vite que les tables de routages deviennent monstrueuses puisqu'elles doivent contenir une entrée pour chaque réseau qu'elles savent router. De plus, la mise en place de l'IPv6 en remplacement de l'IPv4 qui arrivera à saturation rapidement fera littéralement exploser ces tables de routages.

Il est alors constater que la plupart des routeurs se retrouvent à avoir à router sur le même chemin, plusieurs réseaux de la même classe donc ayant potentiellement une partie commune dans leur adresse réseau. Ces routeurs doivent avoir une entrée dans la table pour chaque réseau. S'il était possible de réduire à une seule entrée sur la partie commune de leur adresse réseau, en gros agréger en un réseau virtuel plusieurs réseaux ayant le début de leur adresse en commun, ça serait déjà un gain considérable.

En 1992, le RFC1338 émet l'idée d'abandonner la notion de classe réseau, et de ne considérer finalement chaque réseau quel qu’il soit que comme un (potentiel) sous-réseau d'un réseau plus grand. Le réseau ultime étant alors le réseau 0.0.0.0 / 0.0.0.0 contenant la totalité des (sous-)réseaux possibles et imaginable en IPv4

Les fruits de cette réflexion est l'invention, en 1993, d'un routage inter-domaine sans classe, Classless Inter-Domain Routing concrétisé par le RFC1519 (remplacé depuis par le RFC4632). Le terme CIDR est inventé !

Le principe est très simple. On ne parle plus de classe ni de masque de réseau mais on associe une adresse IP un nombre indiquant les bits de poids fort dans cette adresse qui indiquent le réseau auquel elle appartient, comme ceci : 192.163.0.0/24.
Ca ne change pas grand chose en apparence mais au final ça révolutionne tout, car, désormais, une adresse IP n'appartient plus uniquement au réseau définie par son masque et sa classe, mais appartient à son réseau ainsi qu'à tous les réseaux de niveau supérieurs.
Par exemple l'adresse 192.163.12.6 est, avec la notion de classe, une adresse de classe C et de masque 255.255.255.0. En CIDR, cette adresse appartient donc au réseau 192.163.12.0/24, mais aussi au réseau 192.163.12.0/23 ainsi que 192.163.8.0/21 ou encore 192.163.0.0/16 voire 128.0.0.0/1.

C'est pas clair ?
Prenons les adresses 192.163.12.6/24 et 192.163.17.9/24. Ce sont des adresses de réseaux totalement différents, respectivement 192.163.12.0/24 et 192.163.17.0/24. Mais ces réseaux font respectivement partis de réseaux supérieurs, par exemple, respectivement 192.163.0.0/20 et 192.163.16.0/20, mais aussi 192.163.0.0/19 et 192.163.0.0/19. Bingo, on a un réseau commun, les 2 réseaux initiaux sont donc en fait des sous-réseaux du 192.163.0.0/19.

Imaginons maintenant un routeur qui va router ces 2 adresses. Il se trouve qu'il les routent (ainsi que tous les autres sous-réseaux du 192.16.0.0/19) sur le même chemin. Avec la notion de routage CIDR, il n'est plus nécessaire de saisir autant de route que de sous-réseaux Classe C (32 ici), on saisi plutot juste une route pour le réseau parent commun, à savoir 192.163.0.0/19. De 24 à 19, on économise 31 entrées dans la table de routage.

Bien que la notion de classe et masque IP soit encore enseignée et couramment manipulée, elle n'a plus lieu d'être et devrait systématiquement être remplacé par la notation CIDR.

NOTA : Le terme de "notation CIDR" désigne simplement la notation des adresses IP sous la forme CIDR, à savoir X.X.X.X/YY

NOTA : Le système d'adressage IPv6, mis au point aussi dans les années 1990 se base directement sur le CIDR. Il n'existe pas de notion de classe ou de masque de réseau (en terme de notation d’adresse) en IPv6.

Quelques conversions communes :
Classe A : 0.0.0.0 masque 128.0.0.0 --> 0.0.0.0/1
Classe B : 128.0.0.0 masque 192.0.0.0 --> 128.0.0.0/2
Classe C : 192.0.0.0 masque 224.0.0.0 --> 192.0.0.0/3
Classe D (multicast) : 224.0.0.0 masque 240.0.0.0 --> 224.0.0.0/4

Masque de classe A : 255.0.0.0 --> /8
Masque de classe B : 255.255.0.0 --> /16
Masque de classe C : 255.255.255.0 --> /24

Il est couramment admis que sur internet, une adresse IP est unique dans tout l'internet (adresse unicast). Ceci n'est pas vrai pour certaines adresses.
En effet, pour les adresses dites Anycast, à une adresse donnée, peut répondre différents serveurs, situés généralement dans des zones géographiques* différentes.

Prenons l'exemple d'une multi-nationale, ACME Inc., qui gère différents serveurs dont par exemple un serveur DNS. Cette multi-nationale étant la destination d'un important trafic mondial sur son serveur DNS, elle souhaite pouvoir répartir ce trafic en fonction de la zone géographique*. Elle va donc mettre en place non pas un, mais plusieurs serveurs DNS, répartis dans le monde entier et faire en sorte qu'ils répondent tous à la même adresse comme s'il n'y en avait qu'un seul.

Mais alors comment savoir à quel serveur s'adresser ?
Il n'y a pas lieu de le savoir. Il va sans dire que toutes les machines configurées sur des adresses IP Anycast se doivent d'être des miroir les unes des autres, de sorte que l'on puisse interroger indifféremment l'une ou l'autre. Partant de là, le serveur interrogé est simplement déterminé implicitement par le réseau lui-même au gré des différents routages effectués pour transporter la demande. La requete aboutira au serveur le plus près* du demandeur. Ainsi, si pour une raison quelconque, la route change entre 2 requêtes, les 2 requêtes successives peuvent arriver sur des serveurs différents.

Quelles conséquences pour le client, ou moi l'utilisateur ?
Normalement aucune. Théoriquement, l'IP Anycast doit être totalement invisible pour un client du réseau qui, lui, ne verra toujours qu'une adresse IP présumée unique sur le réseau. Dans la pratique, il est aussi très difficile de mettre en évidence l'IP Anycast. Il faut, par exemple, étudier des traceroutes depuis différents points du réseau mondial pour s’apercevoir que, si l'ip de destination est identique, la ville ou le pays ou elle est susceptible d'être localisée semble différent.

Cependant, ce système peut poser quelques problèmes avec des protocoles comme TCP utilisant une session ou conservant un état. La session étant ouverte sur le premier serveur lors de la première requête, il peut être gênant que les requêtes suivantes arrivent sur d'autres serveurs.
A l'heure actuel IP Anycast est relativement bien déployé mais sur des protocoles stateless, principalement DNS sur UDP mais aussi NTP.

* Il faut concevoir ici les notion de "zone géographique" et "au plus près" en terme de routage et non pas en terme de distance. En routage, on peut ainsi avoir un client plus près d'un serveur à plusieurs milliers de km que d'un autre distant seulement de quelques centaines de km.
Le routage se fait par petit bon d'un équipement à un autre. La notion de "plus près" ne s'applique pas à l'ensemble de la route, mais individuellement à chacun des petits bons à faire. Il est tout à fait possible ainsi que la route "au plus près" ne soit pas la route la plus courte de manière absolue, c'est la plus courte par rapport aux équipements déjà traversés.