L'adresse IP

Il est bon de savoir qu'il existe une adresse « MAC » (Media Access Control), écrite normalement en « dur » dans la ROM de l'interface réseau et donc théoriquement ineffaçable  et infalsifiable (mais ce n'est que la théorie, tous les pirates vous le diront). Cette adresse est réputée unique et décidée par le constructeur de la carte. Elle est la seule adresse exploitée au niveau 2 pour l'identification des hôtes qui dialoguent. Cette méthode ne permettant pas l'interconnexion de réseaux, il va être nécessaire d'ajouter dans la couche supérieure (niveau 3), une adresse logique qui sera attribuée par l'administrateur du réseau, en coordination avec les organismes chargés de gérer l'attribution de ces adresses. Dans le cas qui nous intéresse ici, il s'agit de l'adresse IP.

Internet Protocol

Il existe déjà sur le Net une multitude de pages qui traitent du sujet, ça ne fait rien, mettons en une de plus…

Dans sa version 4, IP définit une adresse sur 4 octets. Une partie définit l'adresse du réseau (NetID ou SubnetID suivant le cas), l'autre partie définit l'adresse de l'hôte dans le réseau (HostID). La taille relative de chaque partie varie suivant le masque de (sous) réseau.

Bien que cette façon de faire soit désormais obsolète (nous verrons plus loin pourquoi), il reste intéressant de l'étudier, pour mieux comprendre la notion de masque de sous-réseau.

Hormis la classe D multicast, destinée à faire de la diffusion d'information pour plusieurs hôtes simultanément, il existe trois classes d'adresses IP:

Comme vous le voyez, la classe A permet de créer peu de réseaux, mais avec beaucoup d'hôtes dans chaque réseau, La classe C faisant l'inverse.

Comment fait-on pour savoir à quelle classe appartient une adresse ? Il y a deux méthodes pour le savoir:

• La triviale, qui consiste à apprendre par cœur le tableau.
• La subtile, qui consiste à retenir la règle, qui est logique.

Voici donc la règle:

• La classe est définie par les bits les plus lourds (les plus à gauche)
• Le bit le moins signifiant pour la classe est toujours un 0
• Les autres sont tous à 1
• La classe A est signalée par un seul bit, donc obligatoirement un 0
• La classe B par deux bits, donc 1 0
• La classe C par trois bits, donc 1 1 0
• La classe D (multicast) par 4 bits donc 1 1 1 0

Il existe même une classe E, dont les bits les plus lourds sont 11110, qui est « réservée à un usage ultérieur ».

Si l'on arrive à retenir la définition ou son image, ça devient facile de retrouver l'étendue de chaque classe:

A ce stade, nous pourrions penser qu'il peut y avoir, par exemple,  128 réseaux de classe A, avec la possibilité d'avoir 16 777 216 hôtes dans chaque réseau. C'est bien entendu, un peu plus compliqué que çà.

Il y a déjà quelques adresses que l'on ne peut pas attribuer à un hôte:

• L'adresse d'hôte =0 (exemple: 192.168.1.0 dans une classe C)
  Par convention, l'adresse IP dont la partie hôte est nulle est réservée à l'identification du réseau.
• L'adresse d'hôte avec tous ses bits à 1 (exemple: 192.168.1.255)
  Par convention, cette adresse signifie que tous les hôtes du réseau 192.168.1.0 sont concernés (Adresse de broadcast).

Et ce n'est pas tout. Nous savons qu'une adresse Internet doit être unique dans un inter réseau. Cette considération, qui ne posait pas trop de problèmes pour des réseaux d'entreprise coupés du reste du monde, devient très restrictive à l'échelle de l'Internet où chaque adresse IP doit être unique à l'échelle planétaire. Ceci représente une contrainte énorme, et qui fait que la pénurie d'adresses IP est une catastrophe annoncée bien plus certaine que celle du bug de l'an 2000. (Rassurez-vous, le prochain protocole IP v6 prévoit de la marge, il faudra juste tout ré apprendre).

Pour permettre aux entreprises de construire leur réseau privé, il a donc été réservé dans chaque classe A, B et C des adresses de réseaux qui ne sont jamais attribuées sur l'Internet (RFC 1918). Tout paquet de données contenant une adresse appartenant à ces réseaux doit être éliminé par le premier routeur établissant une connexion avec l'Internet.

Ces réseaux privés sont:

Le masque de sous-réseau a une importance que peu d'utilisateurs connaissent, elle est pourtant fondamentale. C'est un ensemble de 4 octets destiné à isoler:

• Soit l'adresse de réseau (NetID ou SubnetID) en effectuant un ET logique bit à bit entre l'adresse IP et le masque.
• Soit l'adresse de l'hôte (HostID) en effectuant un ET logique bit à bit entre l'adresse IP et le complément du masque (!masque).

Les masques de sous-réseau par défaut sont, suivant les classes d'adresses:

Par défaut, un masque de sous réseau englobe donc la totalité de la classe.

Mais pourquoi « sous réseau »?

Le principe en est simple: Imaginons que nous disposions d'une classe B. Nous disposons donc de deux octets pour les adresses d'hôtes, soit 65 534 hôtes possibles (les adresses x.x.0.0 et x.x.255.255 sont réservées). Ca ferait tout de même beaucoup de machines sur le même réseau. En pareil cas, il est bien préférable d'organiser son réseau logique en plusieurs sous réseaux, connectés entre eux par des routeurs.

Si par exemple, bien qu'étant en classe B, on choisit comme masque de sous réseau 255.255.255.0, nous obtiendrons 256 sous réseaux de 254 hôtes chacun dans le même réseau. Mais il est possible de définir des masques plus subtils.

Deux hôtes, bien qu'appartenant au même réseau logique, s'ils sont placés dans des sous réseaux logiques différents, ne pourront communiquer entre eux que par l'intermédiaire d'un routeur. Cette solution est très commode pour des réseaux d'entreprise constitués de réseaux locaux distants et même pour des réseaux locaux comportant plusieurs centaines d'hôtes.

Cette façon de faire aboutit malheureusement à un formidable gaspillage d'adresses IP dans la mesure où, à la belle époque, une entreprise pouvait se voir attribuer une classe complète et n'en utiliser qu'une partie.

Avec ce modèle (Classless Inter-Domain Routing), la notion de classe n'existe plus, si ce n'est pour les classes réservées à l'usage privé. Les adresses sont désormais distribuées par bloc, sans tenir compte de leur classe originelle.

L'IANA distribue donc désormais des blocs d'adresses contiguës, délimitées par un masque, toujours de 32 bits, dont les x bits de gauche sont à 1 et les autres à 0. Dans ce modèle, un bloc d'adresse se définit ainsi :

adresse.de.base/x

A titre d'exemple, la classe C 192.168.0.0 avec un masque 255.255.255.0 s'écrirait :

192.168.0.0/24

Ici, nous avons toujours deux adresses remarquables :

• 192.168.0.0 qui symbolise tout le bloc ;
• 192.168.0.255 qui est l'adresse de broadcast pour ce bloc.

La souplesse de cette méthode CIDR réside dans le fait que l'on peut définir désormais un bloc comme ceci :

192.168.0.0/26

Il existe sur toute bonne distribution GNU/Linux un utilitaire nommé « ipcalc » qui va nous décortiquer ce bloc :

~$ ipcalc 192.168.0.0/26
Address:   192.168.0.0          11000000.10101000.00000000.00 000000
Netmask:   255.255.255.192 = 26 11111111.11111111.11111111.11 000000
Wildcard:  0.0.0.63             00000000.00000000.00000000.00 111111
=>
Network:   192.168.0.0/26       11000000.10101000.00000000.00 000000
HostMin:   192.168.0.1          11000000.10101000.00000000.00 000001
HostMax:   192.168.0.62         11000000.10101000.00000000.00 111110
Broadcast: 192.168.0.63         11000000.10101000.00000000.00 111111
Hosts/Net: 62                    Class C, Private Internet

Notez l'inhabituelle adresse de broadcast pour ce bloc. Nous avons donc ici la possibilité d'adresser 62 nœuds, et l'étendue totales des adresses utilisées (réseau et broadcast compris) est :

192.168.0.0 - 192.168.0.63

Voyons le bloc suivant qui pourrait être tout naturellement :

192.168.0.64/26

:~$ ipcalc 192.168.0.64/26
Address:   192.168.0.64         11000000.10101000.00000000.01 000000
Netmask:   255.255.255.192 = 26 11111111.11111111.11111111.11 000000
Wildcard:  0.0.0.63             00000000.00000000.00000000.00 111111
=>
Network:   192.168.0.64/26      11000000.10101000.00000000.01 000000
HostMin:   192.168.0.65         11000000.10101000.00000000.01 000001
HostMax:   192.168.0.126        11000000.10101000.00000000.01 111110
Broadcast: 192.168.0.127        11000000.10101000.00000000.01 111111
Hosts/Net: 62                    Class C, Private Internet

Sur un réseau privé, nous pourrions prendre les deux classes C 192.168.0.0 et 192.168.1.0. En utilisant un masque de type 255.255.254.0, ceci nous permettra de réunir les deux classes C au sein d'un même réseau logique.

En notation CIRD : 192.168.0.0/23

~$ ipcalc 192.168.0.0/23
Address:   192.168.0.0          11000000.10101000.0000000 0.00000000
Netmask:   255.255.254.0 = 23   11111111.11111111.1111111 0.00000000
Wildcard:  0.0.1.255            00000000.00000000.0000000 1.11111111
=>
Network:   192.168.0.0/23       11000000.10101000.0000000 0.00000000
HostMin:   192.168.0.1          11000000.10101000.0000000 0.00000001
HostMax:   192.168.1.254        11000000.10101000.0000000 1.11111110
Broadcast: 192.168.1.255        11000000.10101000.0000000 1.11111111
Hosts/Net: 510                   Class C, Private Internet

Ça fonctionne… Avec quelques restrictions cependant, sur les anciens systèmes. Certaines vieilles piles IP (Windows 95 par exemple) risquent de ne pas accepter les adresses 192.168.0.255 et 192.168.1.0 comme adresses d'hôtes valides (elles devraient être réservées dans un réseau « normal“, nous l'avons vu, mais dans le cas d'un bloc constitué comme celui de l'exemple, il est logiquement possible de les utiliser).

Cet exemple appartient désormais au passé, du temps d'un fournisseur d'accès aujourd'hui disparu.

Un client se connecte et récupère l'adresse 62.161.99.115. C'est une adresse de classe A. Nous allons essayer de voir toutes les informations que l'on peut en tirer, au niveau du réseau. « whois » nous dit:

whois -h whois.geektools.com 62.161.99.115 ...
Query: 62.161.99.115
Registry: whois.ripe.net
Results:

% Rights restricted by copyright. See http://www.ripe.net/ripencc/pub-services/db/copyright.html

inetnum: 62.161.96.0 - 62.161.120.255
...

Cette adresse appartient donc au bloc 62.161.96.0 - 62.161.120.255, qui est une portion du réseau de classe A 62.0.0.0.

Voyons maintenant les informations données par le DHCP. (Exemple sous Linux avec PUMP)

Device eth0
    IP: 62.161.99.115
    Netmask: 255.255.248.0
    Broadcast: 62.161.103.255
    Network: 62.161.96.0
    Boot server 62.161.120.11
    Next server 62.161.120.11
    Gateway: 62.161.96.1
  ...
    Nameservers: 62.161.120.11
    Renewal time: Thu Feb  1 10:17:57 2001
    Expiration time: Thu Feb  1 10:25:27 2001

Le masque de sous réseau est ici aussi inhabituel

~$ ipcalc 62.161.96.0 255.255.248.0
Address:   62.161.96.0          00111110.10100001.01100 000.00000000
Netmask:   255.255.248.0 = 21   11111111.11111111.11111 000.00000000
Wildcard:  0.0.7.255            00000000.00000000.00000 111.11111111
=>
Network:   62.161.96.0/21       00111110.10100001.01100 000.00000000
HostMin:   62.161.96.1          00111110.10100001.01100 000.00000001
HostMax:   62.161.103.254       00111110.10100001.01100 111.11111110
Broadcast: 62.161.103.255       00111110.10100001.01100 111.11111111
Hosts/Net: 2046                  Class A

L'opération consiste simplement en un ET logique bit à bit entre l'adresse et le masque. Mais on avait déjà la réponse en consultant les informations du client DHCP

L'opération consiste ici en un ET logique entre l'adresse et le complément du masque. Bien entendu, HostID + SubnetID doit reconstituer l'adresse IP, ce qui est bien le cas: (62.161.96.0) + (0.0.3.115) = 62.161.99.115

• SubnetID+1=62.161.96.1 .
  Qui est d'ailleurs l'adresse de la passerelle (c'est un choix de FTCI, pas une obligation. Toute adresse dans le même sous réseau aurait aussi bien fait l'affaire)..
  

• C'est SubnetID+!SubnetMask-1
  Pourquoi?
  !SubnetMask-1 correspond à la plus grande HostID possible dans ce sous réseau,
  !SubnetMask correspondant à l'adresse de « l'hôte de broadcast »

L'opération est une somme binaire. Le résultat était prévisible, une fois encore, en regardant les informations du client DHCP. En effet; l'adresse de broadcast pour le sous réseau étudié est 62.161.103.255 (HostID avec tous les bits à 1).

C'est bien, n'est-ce pas, de pouvoir donner une explication rationnelle à tous ces paramètres IP plus ou moins obscurs à première vue…