Extrait du cours de François Laissus intitulé :

Cours d'introduction à TCP/IP

1 Adressage IP

Nous avons dit que l'Internet est un réseau virtuel, construit par interconnexion de réseaux physiques via des passerelles. Ce chapitre parle de l'adressage, le maillon essentiel des protocoles TCP/IP pour rendre transparents les détails physiques des réseaux et faire apparaitre l'Internet comme une entité uniforme.

Un système de communication doit pouvoir permettre à n'importe quel hôte de se mettre en relation avec n'importe quel autre. Afin qu'il n'y ait pas d'ambiguîté pour la reconnaissance des hôtes possibles, il est absolument nécéssaire d'admettre un principe général d'identification.

Lorsque l'on veut établir une communication, il est intuitivement indispensable de posséder trois informations :

1. Le nom de la machine distante,
2. son adresse,
3. la route à suivre pour y parvenir.

Le nom dit `` qui '' est l'hôte distant, l'adresse nous dit `` où '' il se trouve et la route `` comment '' on y parvient.

En règle générale les utilisateurs préfèrent des noms symboliques pour identifier les machines tandis que les processeurs des machines sont plus à l'aise avec les nombres.

Les adresses IP (version 4) sont standardisées sous forme d'un nombre de 32 bits qui permet à la fois l'identification de chaque hôte et du réseau auquel il appartient. Le choix des nombres composants une adresse IP n'est pas laissé au hasard, au contraire il fait l'objet d'une attention particulière notamment pour faciliter les opérations de routage.

Nous remettons à plus tard la correspondance entre ce nombre et une éventuelle représentation symbolique.

Chaque adresse IP contient donc deux informations basiques, une adresse de réseau et une adresse d'hôte. La combinaison des deux désigne de manière unique une machine et une seule sur l'Internet.

1.2 Délivrance des adresses IPv4

On distingue deux types d'adresses IP. Les adresses privées que tout administrateur de réseau peut s'attribuer librement pourvu qu'elle ne soient pas routées sur l'Internet, et les adresses publiques, délivrées par une structure mondiale qui en assure l'unicité. Ce dernier point est capital pour assurer l'efficience du routage, comme nous le verrons au chapitre suivant.

Les adresses à utiliser sur les réseaux privés sont décrites par la RFC 1918 [Y. Rekhter,...1996] :

Les adresses publiques (souvent une seule), sont le plus généralement fournies par le FAI. Qu'elles soient délivrées de manière temporaire ou attribuées pour le long terme, elles doivent être uniques sur le réseau. La question est donc de savoir de qui le FAI les obtient.

C'est L'ICANN (Internet Corporation for Assigned Names and Numbers) qui est chargé au niveau mondial de la gestion de l'espace d'adressage IP. Il définit les procédures d'attribution et de résolution de conflits dans l'attribution des adresses, mais délègue le détail de la gestion de ces ressources à des instances régionales puis locales, dans chaque pays, appelées `` Regional Internet Registries '' ou RIR.

Il y a actuellement trois `` Regional Internet Registries '' opérationnels : l'APNIC pour la région Asie-Pacifique, l'ARIN pour l'Amérique et enfin le RIPE NCC pour l'Europe (l'AfriNIC pour l'Afrique ainsi que le LACNIC pour l'Amérique Latine sont en cours de création). Pour ce qui nous concerne en Europe c'est donc le RIPE NCC (Réseaux IP européen Network Coordination Centre) qui délivre les adresses que nous utilisons.

Les adresses IP sont allouées à l'utilisateur final qui en fait la demande par un `` Local Internet Registry '', ou LIR, autorisé par le RIPE NCC. Un LIR est généralement un FAI ou une grande organisation (entreprise multinationale). Il est sous l'autorité de l'instance régionale de gestion de l'adressage. Ainsi pour un utilisateur (quelle que soit sa taille) changer de FAI implique aussi de changer de plan d'adressage IP, lorsque celles-ci ont été allouées statiquement par le LIR. Les adresses IP sont alors restituées puis ré-attribuées à d'autres utilisateurs.

On compte plus de 2000 de LIRs offrant leurs services en Europe selon le RIPE NCC

2 Anatomie d'une adresse IP

Une adresse IP est un nombre de 32 bits que l'on a coutume de représenter sous forme de quatre entiers de huit bits, séparés par des points (comme au paragraphe 1.2 ci-dessus).

La partie réseau de l'adresse IP vient toujours en tête, la partie hôte est donc toujours en queue.

L'intérêt de cette représentation est immédiat quand on sait que la partie réseau et donc la partie hôte sont presque toujours codées sur un nombre entier d'octets. Ainsi, on a principalement les trois formes suivantes :

Classe A

Un octet réseau, trois octets d'hôtes.

 

Classe B

Deux octets réseau, deux octets d'hôtes.

 

Classe C

Trois octets réseau, un octet d'hôte.

figure III.01

Pour distinguer les classes A, B, C, D et E il faut examiner les bits de poids fort de l'octet de poids fort :

Si le premier bit est 0, l'adresse est de classe A. On dispose de 7 bits pour identifier le réseau et de 24 bits pour identifier l'hôte. On a donc les réseaux de 1 à 127 et 2²⁴ hôtes possibles, c'est à dire 16 777 216 machines différentes (de 0 à 16 777 215).

Les lecteurs attentifs auront remarqué que le réseau 0 n'est pas utilisé, il a une signification particulière (`` tous les réseaux '') comme on le précisera au paragraphe suivant.

De même, la machine 0 n'est pas utilisée, tout comme la machine ayant le plus fort numéro dans le réseau (tous les bits de la partie hôte à 1, ici 16 777 215), ce qui réduit de deux unités le nombre des machines nommables. Il reste donc seulement 16 777 214 machines adressables dans une classe A !

Si les deux premiers bits sont 10

, l'adresse est de classe B. Il reste 14 bits pour identifier le réseau et 16 bits pour identifier la machine. Ce qui fait 2¹⁴= 16 384 réseaux (128.0 à 191.255) et 65 534 (65 536 - 2) machines.

 

Si les trois premiers bits sont 110

, l'adresse est de classe C. Il reste 21 bits pour identifier le réseau et 8 bits pour identifier la machine. Ce qui fait 2²¹=2 097 152 réseaux (de 192.0.0 à 223.255.255) et 254 (256 - 2) machines.

 

Si les quatre premiers bits de l'adresse sont 1110

, il s'agit d'une classe d'adressage spéciale, la classe D. Cette classe est prévue pour faire du `` multicast '', ou multipoint. (RFC 1112 [S. Deering, 1989]), contrairement aux trois premières classes qui sont dédiées à l'`` unicast '' ou point à point.

Ces adresses forment une catégorie à part, nous en reparlons au paragraphe 3.

 

Si les quatre premiers bits de l'adresse sont 1111

, il s'agit d'une classe expérimentale, la classe E. La RFC 1700 précise `` Class E addresses are reserved for future use '' mais n'indique pas de quel futur il s'agit...

 

Enfin, pour conclure ce paragraphe, calculons le nombre d'hôtes adressables théoriquement à l'aide des classes A, B et C :

Certaines adresses IP ont une signification particulière !

Par convention le numéro 0 d'hôte n'est pas attribué. Si une adresse IP contient cette zone nulle cela signifie que l'on adresse le réseau lui-même et aucun hôte en particulier, donc en règle générale l'hôte lui-même. Par exemple, sur toutes les machines, l'adresse 127.0.0.0 indique la machine elle-même (loopback - Cf chapitre IP page ), indépendamment de l'adresse réseau sur lequel elle est connectée.

À l'inverse, si tous les bits de la partie hôte sont à 1, cela désigne toutes les machines du réseaux, c'est ce que l'on appele une adresse de `` broadcast '', c'est à dire une information adressée à tout le monde.

On évite au maximum l'usage d'une telle adresse IP sur les réseaux, pour des raisons d'efficacité (encombrement de la bande passante).

Quelques exemples d'adresses avec une signification particulière :

Remarque : les deux premières adresses, avec un numéro de réseau égal à 0, ne peuvent figurer que comme adresse source dans des cas bien particuliers comme le démarrage d'une station (cf chapitre IP page  et les travaux pratiques associés).

2.3 Sous-réseaux

En 1984 un troisième niveau de hiérarchie est mis en place : le `` subnet '' ou sous-réseau. pour permettre aux administrateurs de gérer plus finement de grands réseaux. La RFC 950 [J. Mogul, J. Postel, 1985] donne plus de précisions, la RFC 1878 [T. Pummill & B. Manning, 1995] est une table de tous les sous-réseaux possibles.

figure III.02

Le `` subnet '' utilise les bits de poids fort de la partie hôte de l'adresse IP, pour désigner un réseau. Le nombre de bits employés est laissé à l'initiative de l'administrateur.

Dans la figure III.02 ci-contre, les bits 6 et 7 de la partie `` host '' sont utilisés pour caractériser un sous-réseau.

Quelques révisions des propriétés des puissances de 2sont souvent nécessaires pour bien assimiler ce paragraphe. La figure suivante en rappelle les valeurs pour les huit premiers exposants :

figure III.03

Nous avons d'une part 2⁷ + 2⁶ = 192, et d'autre part 2⁵ + 2⁴ + 2³ + 2² + 2¹ + 2⁰ = 63. Ce qui permet de caractériser 4 sous-réseaux de 62 machines (63 moins l'adresse de broascast, le `` 0 '' n'étant pas compté). Le calcul des masques et des adresses de diffusion est expliqué dans le tableau suivant :

Soit un total de 62 x 4 = 248 hôtes possibles pour cette classe C avec un masque de sous-réseau, au lieu des 254 hôtes sans.

La machine d'adresse 1 sur chaque sous-réseau, aura comme adresse IP :

Si vous pensez avoir tout compris, le remplissage du tableau suivant dans le cas de la classe C 192.168.192.0 et avec 3 bits pour définir les sous-réseaux ne devrait pas vous poser de problème...

Remarque : On pourra vérifer que la perte d'espace d'adressage pour des hôtes se calcule avec la relation (2ⁿ-1) x 2, où n est le nombre de bits du masque. Ainsi avec 3 bits de masque de sous-réseau, la perte d'espace d'adressage s'élève à 14 hôtes ! Les 254 possibilités (256 moins 0 et 255) de nommage de la classe C se réduisent à 240, amputées de 31, 32, 63, 64, 95, 96, 127, 128, 159, 160, 191, 192, 223 et 224.

2.4 CIDR

En 1992 la moitié des classes B étaient allouées, et si le rythme avait continué, au début de 1994 il n'y aurait plus eu de classe B disponible et l'Internet aurait bien pu mourrir par asphyxie ! De plus la croissance du nombre de réseaux se traduisait par un usage `` aux limites '' des routeurs, proches de la saturation car non prévus au départ pour un tel volume de routes (voir les RFC 1518 et RFC 1519).

Deux considérations qui ont conduit l'IETF a mettre en place le CIDR (`` Classless InterDomain Routing '' ou routage Internet sans classe) basé sur une constatation de simple bon sens :

• S'il est courant de rencontrer une organisation ayant plus de 254 hôtes, il est moins courant d'en rencontrer une de plus de quelques milliers.

  Les adresses allouées sont donc des classes C contigües, attribuées par région ou par continent. En générale, 8 à 16 classes C mises bout à bout suffisent pour une entreprise. Ces blocs de numéros sont souvent appellés `` supernet ''.

  Ainsi par exemple il est courant d'entendre les administrateurs de réseaux parler d'un `` slash 22 '' (/22) pour désigner un bloc de quatre classes C consécutives...

   

• Il est plus facile de prévoir une table de routage pour un bloc d'adresses contigües qu'adresse par adresse, en plus cela allège les tables.

Plus précisement, trois caractéristiques sont requises pour pouvoir utiliser ce concept :

1. Pour être réunies dans une même route, des adresses IP multiples doivent avoir les mêmes bits de poids fort.

    

2. Les tables de routages et algorithmes doivent prendre en compte un masque de 32 bits, à appliquer sur les adresses.

    

3. Les protocoles de routage doivent ajouter un masque 32 bits pour chaque adresse IP (Cet ajout double le volume d'informations) transmise. OSPF, RIP-2, BGP-4 le font.

   Ce masque se manifeste concrêtement comme dans la reécriture du tableau du paragraphe 1.2 :

   10.0.0.0	10.255.255.255	10/8
   172.16.0.0	172.31.255.255	172.16/12
   192.168.0.0	192.168.255.255	192.168/16

   Le terme `` classless '' vient de ce fait, le routage n'est plus basé uniquement sur la partie réseau des adresses.

    

Les agrégations d'adresses sont ventilées selon le tableau suivant :

Tout d'abord il faut préciser qu'une adresse de broadcast est forcément une adresse de destination, elle ne peut jamais apparaître comme une adresse source dans un usage normal des réseaux.

Il y a quatre formes possibles de broadcast :

`` Limited broadcast ''

(255.255.255.255) Une telle adresse ne peut servir que sur le brin local et ne devrait jamais franchir un routeur. Ce n'est malheureusement pas le cas (précisions en cours).

L'usage de cette adresse est normalement limitée à un hôte en phase d'initialisation, quand il ne connait rien du réseau sur lequel il est connecté.

 

`` Net-directed broadcast ''

Tous les bits de la partie hôte sont à 1. Un routeur propage ce type de broadcast, sur option.

 

`` Subnet-directed broadcast ''

C'est le même cas que ci-dessus mais avec une adresses IP comportant des subnets.

 

`` All-subnets-directed broadcast ''

C'est le cas où tous les bits des subnets et hôtes sont à 1. Ce cas possible théoriquement est rendu obsolète depuis la RFC 922 (1993).

 

3 Adressage multicast

En règle générale l'adressage multicast est employé pour s'adresser en une seule fois à un groupe de machines.

Dans le cas d'un serveur vidéo/audio, cette approche induit une économie de moyen et de bande passante évidente quand on la compare à une démarche `` unicast '' : un seul datagramme est routé vers tous les clients intéressés au lieu d'un envoi massif d'autant de datagrammes qu'il y a de clients.

Les adresses de type `` multicast '' ont donc la faculté d'identifier un groupe de machines qui partagent un protocole commun par opposition à un groupe de machines qui partagent un réseau commun.

La plupart des adresses multicast allouées le sont pour des applications particulières comme par exemple la découverte de routeurs (que nous verrons ultérieurement lors du routage IP) ou encore la radio ou le téléphone/vidéo sur Internet (`` Mbone ''). Les plus couramment utilisées sur un lan sont :

3.1 Adresse de groupe multicast

Si une adresse multicast démarre avec les bits 1110 par contre pour les 28 bits suivants son organisation interne diffère de celle des classes A, B et C.

cm figure III.04

• Les 28 bits n'ont pas de structure particulière par contre on continue à utiliser la notation décimale pointée : 224.0.0.0 à 239.255.255.255.

   

• Un groupe d'hôtes qui partagent un protocole commun utilisant une adresse multicast commune peuvent être répartis n'importe où sur le réseau.

   

• L'appartenance à un groupe est dynamique, les hôtes qui le désirent rejoignent et quittent le groupe comme ils veulent.

   

• Il n'y a pas de restriction sur le nombre d'hôtes dans un groupe et un hôte n'a pas besoin d'appartenir à un groupe pour lui envoyer un message.

3.2 Adresse multicast et adresse MAC

Une station Ethernet quelconque doit être configurée pour accepter le multicast, c'est à dire pour accepter les trames contenant un datagramme munis d'une adresse IP de destination qui est une adresse multicast.

Cette opération sous entend à juste titre que la carte réseau sait faire le tri entre les trames. En effet les trames multicast ont une adresse MAC particulière : elles commencent forcément par les trois octets 01:00:5E. Ceux-ci ne désignent pas un constructeur en particulier mais sont possédés par l'ICANN (ex IANA).

Restent trois octets, soit 24 bits dont le premier est forcément à 0 pour désigner les adresses de multicast (contrainte de la RFC 1700), ce qui conduit au schéma suivant :

cm figure III.05

Du fait qu'il n'y a pas assez de place dans l'adresse MAC pour faire tenir les 28 bits du groupe multicast, cette adresse n'est pas unique. On peut même préciser que pour chaque trame comportant une adresse multicast il y a 2⁵ adresses IP de groupes multicast possibles !

Ce qui signifie que si les 23 bits de poids faible ne suffisent pas à discriminer la trame il faudra faire appel au pilote de périphérique ou à la couche IP pour lever l'ambiguîté.

Quand une trame de type multicast est lue par la station Ethernet puis par le pilote de périphérique, si l'adresse correspond à l'une des adresses de groupe multicast préalablement configurées, le datagramme franchit la couche IP et une copie des données est délivrée aux processus qui ont `` joint le groupe multicast ''.

La question est de savoir comment les trames de type multicast atteignent justement cette station Ethernet ? La réponse se trouve dans un protocole nommé IGMP et que nous examinerons dans le prochain chapitre concernant IP.

4 Conclusion et bibliographie

Pour conclure ce chapitre sur l'adressage IP, il faut nous donner quelques précisions supplémentaires.

Jusqu'à présent nous avons désigné un hôte par son adresse IP. Cette démarche n'est pas exacte si on considère par exemple le cas d'une passerelle, connectée physiquement à au moins deux réseaux différents, avec une adresse IP dans chacun de ces réseaux.

On dira donc maintenant qu'une adresse IP identifie non pas un hôte mais un interface. La réciproque n'est pas vraie car un même interface peut collectionner plusieurs adresses IP. Toutes permettent d'atteindre cet interface, on parle alors d'`` alias IP '' et de `` réseaux virtuels ''... Nous aurons l'occasion de revenir sur ces notions à la fin de ce cours.

On dit d'une machine ayant au moins deux adresses IP qu'elle est du type `` multi-homed ''.

En général une passerelle qui met en relation n réseaux possède n adresses IP différentes (une dans chaque réseau), mais ce n'est pas une obligation (nous verrons quelle peut en être l'utilité à la fin de ce cours).

figure III.06

La figure III.06 met en situation deux hôtes, A et B, en relation via une passerelle G. Si les `` messages '' et les `` paquets '' sont identiques, par contre les `` datagrammes '' et les `` trames '' diffèrent puisqu'il ne s'agit plus du même réseau physique. Dès que nous aurons examiné le fonctionnement de la couche IP nous reviendrons sur cette figure pour en expliquer le fonctionnement (voir page ).

Pour en savoir plus :

RFC 0950

S J. Mogul, J. Postel, `` Internet standard subnetting procedure '',
08/01/1985. (Pages=18) (Format=.txt) (STD 5)

 

RFC 1112

S S. Deering, `` Host extensions for IP multicasting '', 08/01/1989.
(Pages=17) (Format=.txt) (Obsolètes RFC0988) (STD 5)

 

RFC 1518

`` An Architecture for IP Address Allocation with CIDR ''
Y. Rekhter, T. Li. September 1993. (Format: TXT=72609 bytes) (Status: PROPOSED STANDARD)

RFC 1519

PS V. Fuller, T. Li, J. Yu, K. Varadhan, `` Classless Inter-Domain
Routing (CIDR): an Address Assignment and Aggregation Strategy '',
09/24/1993. (Pages=24) (Format=.txt) (Obsoletes RFC1338)

 

RFC 1466

I E. Gerich, `` Guidelines for Management of IP Address Space '',
05/26/1993. (Pages=10) (Format=.txt) (Obsolètes RFC1366)

 

RFC 1467

`` Status of CIDR Deployment in the Internet. ''
C. Topolcic. August 1993. (Format: TXT=20720 bytes)
(Obsoletes RFC1367) (Status: INFORMATIONAL)

 

RFC 1700

`` Assigned Numbers. '' J. Reynolds, J. Postel. October 1994.
(Format: TXT=458860 bytes) (Obsolètes RFC1340)
(Also STD0002) (Status: STANDARD)

 

RFC 1878

`` Variable Length Subnet Table For IPv4. ''
T. Pummill & B. Manning. December 1995.
(Format: TXT=19414 bytes) (Obsolètes RFC1860) (Status: INFORMATIONAL)

 

RFC 1918

`` Address Allocation for Private Internets. '' Y. Rekhter, B. Moskowitz,
D. Karrenberg, G. J. de Groot & E. Lear. February 1996.
(Format: TXT=22270 bytes) (Obsolètes RFC1627, RFC1597) (Also BCP0005)
(Status: BEST CURRENT PRACTICE)

 

• W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols - Addison-Wesley

   

• Douglas Comer - Internetworking with TCP/IP - Principles, protocols, and architecture - Prentice-Hall

   

• Christian Huitema - Le routage dans l'Internet - EYROLLES