COURS SUR L’0PTIMISATION

DES PROTOCOLES :
OSI ET TCP-IP
 2

LE SOMMAIRE
CHAPITRE 1 : L'ANALOGIE

Le parallèle entre votre armoire de rangement vestimentaire et le modèle OSI. Lisez-ça, c'est
édifiant !

CHAPITRE 2 : QUI, QUOI, POURQUOI ?

Plus sérieusement, qui a développé l modèle OSI, quelle est sa structure générale et comment
justifier son existence ?

CHAPITRE 3 : COMMENT ÇA MARCHE ?

Comprendre le mécanisme de l'encapsulation sous le modèle OSI par l'analogie avec La Poste
! Mais, l'encapsulation est-elle spécifique au modèle OSI ? La réponse est dans cette page ...

CHAPITRE 4 : STRUCTURE GENERALE

Rôles et fonctions générales des couches. Notion de services rendus entre couches. Le
dialogue inter-couche... Accrochez-vous un peu ...

CHAPITRE 5 : LA LIAISON DE DONNEES

Comment simplifier une connexion complexe en un aboutement de connexions simples ? (On

n'est pas loin du pléonasme !)

Mais d'abord c'est quoi la différence entre une DTE et un DCE ?

CHAPITRE 6 : LA COUCHE PHYSIQUE

Comment transmettre des bits sur deux fils ? Quand est-il du rôle du modem ? Est-ce si simple
?

A quoi faut-il penser pour émettre des données à travers un support physique ?

CHAPITRE 7 : LA COUCHE LIAISON

Un support n'est jamais parfait ! Il faut sans cesse le contrôler ! La couche 2 veille au grain
!Allez donc voir quelques une de ses fonctions les plus intéressantes !

CHAPITRE 8 : LA COUCHE RESEAU

Un réseau informatique est au moins aussi complexe que le réseau autoroutier français ! Il
faut pourtant pouvoir y circuler ! Alors on utilise des notions d'adresses, de priorité, de
fragmentation, etc ...En prime un petit exposé sur les notions de "mode connecté" et "non
connecté", allez voir !
 3

COUCHE 9 : LA COUCHE TRANSPORT

Là où on parle de gestion de flux, de connexion de process et de frontière entre l'informatique

et la téléinformatique ! Pourquoi pas ? Après tout il s'est tellement fatigué à écrire tout ça !

CHAPITRE 10 : LA COUCHE SESSION

Dans le chapitre "Pourquoi faire simple, quand on peut faire compliqué !" Une couche
apparemment semblable aux autres mais reconstruite de toutes parts ... Ca vous rappelle pas,
Monsieur Bionique ça ?

CHAPITRE 11 : LA COUCHE PRESENTATION

Avis aux traducteurs ! Votre couche est LA !! L'endroit où l'on parle d'adaptation de syntaxe,
d'espéranto et autres langages universels, pour une meilleure compréhension de tous ! La CEE
quoi !

CHAPITRE 12 : LA COUCHE APPLICATION

Du service ! Du service ! Voilà le rôle de la couche Application ! Allez donc voir tout ce qu'elle
peut vous apporter ! Enfin, surtout à votre application !
Ici on vous parlera de transfert de fichier FTAM, annuaire X500, messagerie X400 etc ...

CHAPITRE 13 : LA CONCLUSION

L'essentiel n'est pas ce que l'on croit ! Douze pages pour ne finalement retenir qu'une phrase
!

CHAPITRE I : PREMIERE APPROCHE : L'ANALOGIE

 4

I.1. L'ARMOIRE
Vous êtes tous des gens très ordonnés, c'est connu ... Vous disposez, tous, d'une armoire pour
y ranger vos vêtements, j'en suis sûr ! Nous allons supposer que cette armoire comporte 7
étagères. Nous allons aussi supposer qu'il fait extrêmement froid (ça m'arrange !), et que vous
avez besoin de vous couvrir chaudement.

Le matin, les réveils sont durs ! Une nuit à surfer sur le Web, c'est exténuant ! Vous ne voulez
plus passer des heures à chercher après vos habits sur ces étagères, les yeux à demi-fermés,
pestant pour trouver cette satanée paire de chaussettes. Donc, un jour de grande illumination,
vous réfléchissez à une méthode de rangement de vos vêtements qui vous permettent à coups
sûrs de trouver rapidement et efficacement vos affaires.

Vous élaborez la technique suivante :

• Vous attribuez une étagère par type de vêtements (une pour les chaussettes, une pour
les chemises, une pour les sous-pulls, une pour les pulls, et ainsi de suite)
• Vous savez que tous les matins vous commencez d'abord par mettre vos chaussettes,
ensuite votre caleçon, puis un maillot de corps (il fait froid !), puis un sous-pull, puis
une chemise, puis le pantalon et enfin le pull ! Diantre que la température est basse !
• Vous vous dites : "Je ne veux plus réfléchir pour savoir sur quelle étagère sont les pulls
ou les chemises ou autres". Je veux pouvoir m'habiller les yeux fermés.
• Vous décidez donc d'affecter l'étagère la plus haute (étage numéro 7) aux vêtements
que vous mettez en premier (en l'occurence les chaussettes !), puis l'étagère 6 aux
caleçons, puis la 5 aux maillots de corps et ainsi de suite !!

Maintenant plus de soucis le matin ! Vous tendez la main tout en haut, attrapez une paire de
chaussettes, l'enfilez, puis étagère inférieure les caleçons, et ainsi de suite ... Vous venez de
rationnaliser, de structurer votre méthode d'habillement matinale ! Le modèle OSI c'est la même
chose ! (

I.2. RAPPROCHEMENT AVEC L'ANALOGIE

 5

I.3. LE MODELE EN COUCHE

En téléinformatique il existe aussi une méthode de rangement des fonctions nécessaires à la
mise en oeuvre de systèmes de transmissions de données plus ou moins complexes. Cette
méthode est en fait une proposition d'organisation des protocoles et de leurs échanges, c'est
le Modèle OSI.

Vous n'imaginez pas le nombre de protocoles, de mécanismes et d'équipements qui sont

nécessaires pour vous permettre de lire cette page, vous qui êtes situé à Marseille alors qu'elle
est enregistrée sur un serveur à coté de Paris ! La liste est tout simplement affolante ! Il y a
tellement de concepts, de normes et de protocoles que pour s'y retrouver il a fallu mettre au
point une méthode de classement, permettant de rationnaliser, de structurer la pensée
téléinformatique.

Comme votre armoire, ce modèle comporte 7 étagères, appelées en fait : des couches. Comme
dans votre armoire, tous les protocoles rangés sur une couche (étagère) ont des rôles similaires.
Toutes vos chaussettes de l'étagère 7 ont pour rôle de protéger vos pieds du froid. Tous les
protocoles de la couche 7 OSI ont pour rôle de rendre des services à l'application (messagerie,
supervision, annuaire, gestion des autorisations d'accès, etc...). Il en va de même pour toutes
les couches.

Vous n'avez pas poussé le vice jusqu'à étiqueter ou nommer vos étagères d'armoire, d'autant
plus que c'est pour vous habiller les yeux fermés ! Les concepteurs du modèle OSI l'ont fait !
Chaque couche est identifiable par les points suivants :

• Elle a un nom
• Elle a un niveau (de 1 à 7)
• Elle a un rôle bien défini au sein du modèle OSI qu'elle est la seule à réaliser
• Pour remplir ce rôle, elle rend des services aux couches qui lui sont directement
adjacentes (au-dessus et en dessous d'elle). Chaque couche dispose d'un certain
nombre de normes de services, qui définissent les services à rendre aux couches .
 6

• Pour rendre ces services elle dispose de protocoles. Le protocole est un langage, une
méthode de traitement de l'information qui, parce qu'il est normalisé, permet aux
couches de mêmes niveaux de se comprendre ... Je sais ! Ca se corse, mais on va y
revenir !

I.4. CONCLUSION INTERMEDIAIRE

Voici une toute première approche du modèle OSI, par l'analogie. Même si la méthode peut
donner à sourire, retenez la ! Vous verrez que nous ferons souvent des rappels à cette
analogie. Il nous reste cependant encore beaucoup de choses à voir sur ce modèle OSI :

• OSI : qu'est-ce que ça veut dire ?

• Quels sont les noms, rôles et fonctions des couches ?
• Qui l'a fait ?
 7

I.5. MODELE O.S.I : QUI, QUOI, POURQUOI ?

I.5.1 QUOI : QU'EST-CE QUE ÇA VEUT DIRE ?

Modéle OSI : Model for Open Systems Interconnexion : Interconnexion de systèmes ouverts
(en français dans le texte).

Système ouvert : Se dit d'un système informatique (généralement un ordinateur, mais pas
forcément) qui désire échanger des données avec un autre. Il est alors sous-entendu que ces
systémes sont interconnectés par un réseau. Celui-ci peut partir de sa plus simple expression
(une liaison filaire unique et directe) à une configuration extrêmement complexe (Internet,
par exemple !).

I.5.2. QUOI : QU'EST-CE QUE C'EST ?

Le modèle OSI a été mis au point pour faciliter les échanges de données entre systèmes ouverts (nous
dirons dorénavant : entre équipements ou systèmes informatiques). C'est un environnement
(ou modèle) normalisé. Cette normalisation est complexe et intervient à différents niveaux :

• Il existe une norme de structure définissant le nombre des couches, leurs rôles, leurs
places dans l'environnement et la méthode de circulation des informations entre elles.
• Il existe, pour chaque couche, un ensemble de normes de services, qui définissent les
fonctions (ou services) rendues par la couche aux autres couches directement
adjacentes (directement au-dessus ou en-dessous d'elle). Ces normes définissent des
classes de services, pour une couche donnée il peut exister plusieurs classes de services.
• Il existe, pour chaque couche, des normes protocolaires. Une même couche peut donc
supporter plusieurs sous-programmes (ou protocoles, nous reviendront sur le sujet un
peu plus tard), qui lui permettent de rendre les services définis par les normes de
services.

Toutes ces normes sont généralement recensées par des Avis (ou Recommandations)
émanant de l'ITU-T (nous allons y venir) ou de l'ISO (là aussi on va y venir). Les avis ITU-T
 8

relatifs au modèle OSI commencent tous par Xnuméro (exemple X224) et par leur équivalent
ISO (exemple ISO 8073).

I.5.3. QUI : QUI L'A DEFINI, CE MODELE ?

Ce modèle relève des travaux de l'ITU-T (ex CCITT) qui est une émanation européenne de l'ISO.
C'est clair ?

En gros, il existe une hiérarchie dans les organismes de normalisation :

• ISO : International Standardization Organisation (He oui ! Rien à voir avec OSI ! Mais
pour la petite histoire ...) : Organisme de Standardisation International (soit donc, OSI
en français !). Regroupement de constructeurs et administratifs mondiaux qui
définissent des normes allant de la forme standard d'une lunette de WC à la méthode
de codage des informations émises par Voyager II vers Houston ! (J'exagère à peine !).
Allez voir ici, et vous verrez de quoi ils s'occupent !
• ITU : International Télécommunication Union, émanation essentiellement européenne
de l'ISO en charge spécifiquement des problèmes de télécommunications au sens large
(téléphonie compris). C'est le nouveau nom du CCITT. Allez voir ici, et vous verrez les
principaux domaines d'application de l'UIT-T.
• En descendant encore un peu dans la hiérarchie on trouve les organismes nationaux
de normalisation, l'AFNOR en France et aussi la DGPT (Direction Générale des Postes
et Télécommunications), l'ANSI (American National Standard Institute) aux U.S ou
l'IEEE (Institute of Electrical and Electronics Engineers : Merci à Papy pour cette
précision).

Bref, une pléthore d'organismes de normalisation, se partageant l'intéressant travail,

consistant à se réunir régulièrement dans un pays chaud, ensoleillé et en bord de plage
généralement, pour débattre longuement en sirotant un cocktail, du bien fondé de telle ou
telle normalisation, et des modifications à y apporter. Je plaisante !!

Les principes de normalisation sont extrêmement complexes, et on se perd facilement dans

la forêt dense des organismes. Mais un principe se dégage généralement :

• Un constructeur fabrique un équipement qui veut rendre certaines fonctions.

• Cet équipement plaît beaucoup aux utilisateurs, qui l'achètent à la pelle !
• Le constructeur devient alors très implanté. Il peut (mais pas toujours) publier ses
travaux pour que d'autres fassent la même chose, et permettre ainsi aux utilisateurs
d'acheter, d'acheter, d'acheter, ...
• Un jour, le constructeur se réveille et se rend compte que ce qu'il a créé est devenu :
une norme de fait. Tout le monde est d'accord, il y a consensus, pour utiliser ses
normes à lui ! Quelle consécration !
• Alors, le constructeur (attention, c'est pas toujours lui qui décide !) peut proposer ses
travaux pour une normalisation nationale (ou internationale).
• Ses recommandations, subiront généralement des petites modifications, pour rentrer
dans le moule des spécifications normalisées. Mais ce ne sera généralement pas trop
loin.
 9

• Enfin l'organisme de normalisation nationale (IEEE par exemple) peut proposer cette
norme au niveau international au prix parfois de quelques nouvelles modifications.
Alors là ! C'est la mise en orbite du constructeur !

I.5.4. POURQUOI : OU PLUTOT POUR QUOI FAIRE ?

Pour expliquer simplement, logiquement, de manière structurée comment les échanges de
données entre systèmes ouverts à travers un réseau peuvent avoir lieu. Il était, vous l'aurez
compris, nécessaire de définir un modèle de communication auquel chacun pourrait se
raccrocher pour structurer son propre modèle de communication.

L'ISO a donc, à travers le modèle OSI, fourni aux téléinformaticiens une formidable boîte à
outils. Celle-ci est non seulement une boîte avec des casiers bien identifiés pour ranger les
choses (protocoles) à leur place, mais elle est livrée pleine (ou presque). En effet, liées à cet
environnement nous trouverons pléthore de normes protocolaires directement utilisables :
les outils, quoi !

I.5.6. CONCLUSION INTERMEDIAIRE

Vous savez maintenant, qui a développé OSI (pour information, les travaux ont commencé en
1970 tout de même !), à quoi il sert et pourquoi il est là. Cela n'est déjà pas si mal !

Mais au fait :

• Comment ça marche ?
• Quelle est sa structure ?
• Quels sont les protocoles qui sont associés à cet environnement ?
• Comment l'utilise-t-on ? Et d'ailleurs, l'utilise-t-on vraiment ?

Encore beaucoup de questions auxquelles je vais tenter de répondre dans les pages suivantes.

I.5.7. COMMENT ÇA MARCHE ?

 10

Circulation entre couches

A. L'ENCAPSULATION : L'HISTOIRE DES POUPEES RUSSES OU DE LA

POSTE
Démarrons de la couche 4 si vous le voulez bien. Cette couche nous le verrons plus tard
s'occupe de structurer des segments de message à émettre à une autre extrémité. Elle va
transmettre ce segment à la couche 3 (dite couche RESEAU), qui aura en charge de placer
tout ou partie du segment dans un paquet. Ce paquet sera émis sur le réseau, et acheminé
ainsi à l'autre extrémité. Autrement dit, nous mettons un segment dans un paquet.

Ce qui est vrai entre la couche 4 et la couche 3 est, pour ainsi dire, vrai entre toutes les
couches adjacentes. Ainsi la donnée émise par l'application sera, tour à tour, enrobée par
chaque couche, au fur à mesure de sa descente dans le modèle OSI : c'est l'encapsulation.

Pour comprendre mieux le phénomène, imaginez que vous ayez à émettre un paquet
contenant des chèques cadeaux à un groupe de personne par la poste. Ce paquet contient
des enveloppes pour 4 personnes travaillant toutes au même endroit. Ces enveloppes
contiennent chacune un chèque cadeau, une enveloppe par personne. Pour réaliser cet
envoi, vous procéder de la manière suivante :
 11

B. ENCAPSULATION
• Vous commencez par prendre un chèque cadeau, que vous glissez dans une
enveloppe.
• Vous inscrivez le nom de la personne destinataire. Vous répétez l'opération pour les 4
chèques et enveloppes.
• Vous allez ensuite demander à votre service courrier de placer les quatre enveloppes
dans un même paquet, en précisant l'adresse de destination du paquet.
• Le service courrier va placer les quatre enveloppes dans le paquet, et attendre le
passage du facteur.
• Le facteur prendra le paquet et l'emmènera au centre de tri (sans passer par le bureau
de poste, parce que ça m'arrange !), en veillant à ne pas perdre, ni détériorer le
paquet. Pour cela, il l'aura placé pendant le trajet dans une boîte hermétique (et
pourquoi pas ?).
• Au centre de tri on sort le paquet de la boîte, on examine l'adresse, et on le replace
dans une boîte à destination de l'adresse requise, ou d'un centre de tri le plus proche.
• Et ainsi de suite, jusqu'à livraison du paquet ...

Le modèle OSI utilise exactement ce principe, on emballe le chèque dans une enveloppe
(j'encapsule le message dans un segment), on emballe les enveloppes dans un paquet
(j'encapsule les enveloppes dans un paquet), etc...

Au final dans la voiture du facteur, il y a une boîte, dans la boîte, un paquet, dans le paquet,
quatre enveloppes, dans l'enveloppe un chèque cadeau ... (Devinez, quoi qui n'y a dans le petit
bois derrière chez moi !). Les poupées russes quoi !! C'est le principe d'encapsulation.
 12

Le stack TCP-IP

ENCAPSULATION : EST-CE SPECIFIQUE A OSI ?

Pas du tout ! En fait on fait constamment de l'encapsulation protocolaire, sans pour autant
que ce soit spécifique à OSI.

Prenons le cas de l'environnement TCP/IP. Sur l'image ci-contre vous avez une représentation
simplifiée du stack TCP/IP (Stack = Pile = Empilement = Couches).

Lorsque vous faites un transfert de fichier par FTP, votre fichier est placé dans des messages
FTP, eux-mêmes inclus dans des segments TCP, eux-mêmes placés dans des paquets IP, qui
sont très probablement mis dans des trames PPP ou HDLC !! Ca c'est bien de l'encapsulation
non ? Et pourtant ...

Sachez que TCP/IP n'est pas normalisé ISO, donc encore moins OSI (Elle est claire la différence
entre ISO et OSI ?). En téléinformatique tout fonctionne par encapsulation, alors qu'en
informatique on fonctionne plutôt en conversion. Il existe énormément d'environnements
non normalisés ISO (ou OSI), TCP/IP, Novell/IPX, AppleTalk, SNA, Digital Phase IV (DEC).
Cependant, vous pouvez dire que IP de TCP/IP, IPX de Novell, PC de SNA, DRP de DSA sont des
protocoles de niveau 3 OSI !! Un puriste vous sautera à la gorge. Quelqu'un de plus tolérant
comprendra par là, que ces protocoles ont en charge des fonctions de routage des données
dans le réseau. A ce titre on peut attendre de leur part des fonctions d'adressage virtuel, de
segmentation, de priorisation, de séquencement, etc ...

Commencez - vous à comprendre l'utilité du modèle OSI ? Lorsque vous le connaîtrez vous
pourrez plus facilement situer les protocoles et leur fonctions.

Nous reviendrons sur l'encapsulation lorsque nous étudierons la circulation verticale des
données dans l'environnement OSI.
 13

CONCLUSION INTERMEDIAIRE
Ce chapitre avait pour but de vous présenter la manière dont on peut faire transiter des
données à travers un empilement protocolaire. Ces empilements sont très nombreux et
souvent assez différents dans le rôle ou les services rendus par chaque protocole (ou couche).
Il n'en reste pas moins que les mécanismes d'encapsulation sont similaires. Vous avez donc
une idée maintenant du : Comment ça marche ?

Il serait maintenant temps d'enfin regarder de plus près le contenu de ce fameux modèle.
Répondons plus précisément au : Qu'est-ce que c'est ?

QUELLE EST SA STRUCTURE ?

DEFINITION GENERALE DES COUCHES

Il est enfin temps de présenter et nommer ces fameuses couches. Nous ne présenterons ici
que les numéros, noms et rôles des couches, nous détaillerons plus tard, couche par couche
les fonctions (ci-contre).

Encore une fois, souvenez-vous : Chaque couche est identifiable à un sous-programme qui
interface directement avec les couches adjacentes (GO Sub(paramètres) pour les accros du
Basic d'antan !).

En vérité une couche N-1, rend des services à une couche N (par exemple la couche Réseau
Niv. 3 rend un service d'acheminement des paquets dans le réseau à la couche 4, dite couche
Transport). Ceci nous amène à regarder d'un peu plus près les charnières qui relient les
couches OSI.
 14

LA CIRCULATION VERTICALE DES DONNEES

Très sérieusement cette fois, examinons le principe d'échange des données entre couches.
Une couche N+1 (par exemple la couche 4 : Transport) désire transmettre des données à un
autre ordinateur, de l'autre coté d'un réseau. Elle va transmettre son paquet de données à la
couche réseau :

• Le paquet de donnée en question, a une structure que seule la couche 4 connaît, il est
structuré selon le langage de cette couche. Ce paquet est un mot, une unité de
données, que le protocole de la couche 4 reconnaît, sait lire et interpréter. C'est l'unité
de données du protocole, la Protocol Data Unit (PDU) de la couche 4 (N+1).
• Pour faire sa demande de service à la couche N, la couche N+1, doit transmettre un
certain nombre de paramètres. Elle doit, par exemple, demander à la couche réseau
d'émettre les données transmises, au correspondant ayant l'adresse réseau X.
• Rappelez-vous lorsque vous avez transmis à votre service courrier les 4 lettres à mettre
dans un paquet, vous avez transmis les lettres (les données, votre PDU) et l'adresse de
destination. A cette occasion vous avez peut-être fait une demande officielle en
remplissant tous les champs du formulaire 95B-C2510 Appendice 2024 (Comme à la
Sécu !). Vous avez fait une demande de service standard, avec un formulaire adéquat,
que vous avez transmis au bon service. Vous avez en fait utiliser une unité de service
de donnée, la Service Data Unit (SDU) pour faire votre demande. Cette SDU a été
transmise par un point de passage obligé qui a validé la demande (le secrétariat du
service courrier), vous êtes passé par le point de demande de service, le Service Access
Point (SAP), les informaticiens parlent plutôt d'API (Application Program Interface).
• Pour émettre les 4 lettres, le service courrier les a placé dans un paquet. Sur ce paquet
il a collé une étiquette comportant l'adresse de destination du paquet. L'adresse que
vous aviez transmise. Cette adresse, il l'a par contre rédigé selon ces propres normes.
Il l'a peut-être inscrite en code barres afin de faciliter le traitement de la Poste (Et alors
? Si ça m'arrange !). Il a donc placé sur le paquet son propre identifiant, permettant à
son protocole de contrôler le paquet (sous-entendu : Contrôler son acheminement). Il
a donc apposé au paquet formé son Protocol Control Identifier (PCI).
 15

• Le paquet et son adresse forment maintenant une entité complète qui sera remise au
postier en lui demandant de bien vouloir prendre en charge son acheminement
jusqu'au centre de tri. Une nouvelle SDU du service courrier, cette fois, vers le postier
!

Vous voyez encore une fois, que l'analogie avec La Poste permet d'expliquer assez simplement
les termes et mécanismes de l'environnement OSI.

CONCLUSION INTERMEDIAIRE
Vous savez donc maintenant qu'une couche génère une PDU, qu'elle fait des demandes de
services à la couche inférieure à travers des SDU, la couche inférieure est accessible par un
SAP. Sachant que chaque couche génère un certain nombre d'informations supplémentaires
qui viennent encapsuler la donnée transmise pour former la PDU de la couche : ces données
supplémentaires sont appelées PCI.

Vous connaissez aussi maintenant le rôle, le numéro et le nom de chaque couche. Vous savez
pourquoi et qui a conçu ce modèle OSI, mais vous n'avez pas encore réellement une idée
précise des fonctions de chaque couche.

Les chapitres suivants n'ont pas pour ambition de présenter une description exhaustive des
services rendus par chaque couche, ou une analyse détaillée de chaque protocole utilisable
dans l'environnement OSI. Ce serait là une tâche gigantesque qui pourrait facilement donné
lieu à un ouvrage complet. Pour chaque couche je ne présenterai donc que les points suivants
:

• Le rôle de la couche dans l'environnement OSI (nous l'avons déjà vu partiellement)

• Une liste de fonctions exemples de cette couche avec une explication succincte. Cette
liste sera, je l'ai déjà dit, incomplète et les éléments présentés n'ont aucun caractère
péremptoire sur d'autres que je n'aurai pas présenté. C'est simplement MA sélection,
qui n'engage que moi, et qui, avouons-le, m'arrange !
• Des noms de normes et protocoles associables à la couche. Certains de ces protocoles
ne seront d'ailleurs pas forcément normalisés ISO. Mais ils seront représentatifs des
fonctions de la couche et communément reconnu par la communauté
téléinformatique comme relevant de la dite couche.

Mais patience ... Avant de passer à cette description, si vous êtes novices, je vous conseille de
lire la page suivante. Il est en effet important de situer l'influence, la portée d'une couche dans
une communication informatique. Les éléments qui vous relient vous et votre PC à votre
serveur Internet aux US, sont nombreux. Il est donc nécessaire, dans un premier temps de
procéder à une schématisation de cette liaison.

LA LIAISON DE DONNEES
 16

LA LIAISON DE DONNEES DE BASE

Toute chaîne de transmission, aussi complexe soit-elle, peut-être simplifiée en une suite de
liaisons de données de base. Cette représentation de base, permet d'identifier les éléments
fondamentaux nécessaires à une transmission entre deux systèmes distants.

Dans cette chaîne on trouve les DTE (Data Terminal Equipment) - ETTD (Equipement Terminal
de Traitement de Données) qui effectuent le traitement des données. Certes ils effectuent le
2+2=4, mais aussi la préparation à la transmission (couches 7 à 2 et une partie de la couche
1).

La gestion de la communication est assurée par le contrôleur de communication interne à

l'ETTD.

Dans certains environnements "gros systèmes" tels qu'IBM (SNA), Digital (DNA) ou Bull (DSA),
la fonction de contrôleur de communication est sortie de l'ordinateur, afin de décharger la
CPU centrale des traitements liés à la transmission.
 17

L'ETTD est alors appelé un "Hôte" ou "Host", il est relié par un bus ou un lien très haut débit,
appelé parfois "Canal", au contrôleur de communication externe, parfois appelé "Frontal".

A l'attention des puristes : Je sais ! Je sais ! Mais c'est plus simple comme ça !

ENCHAINEMENT DE LIAISONS DE DONNEES

Lorsque vous êtes connecté avec votre PC au réseau Internet, vous êtes raccordés à un serveur
par l'intermédiaire de votre ligne téléphonique. Cet ensemble forme une liaison de données
de base. Depuis ce serveur vous allez peut-être atteindre d'autres sites, en empruntant des
liaisons entre serveurs. Ce sont d'autres liaisons de base. Votre communication avec le dernier
serveur de la chaîne est donc supportée par un enchaînement de liaisons de données de base
! Chaque serveur joue le rôle d'un DTE et tous les modems de chaque ligne le rôle d'un DCE.

TRANSPOSITION DU NIVEAU SUPPORT

"Tout dépend de l'endroit où on se place, et de l'idée qu'on s'en fait ...", disait un de mes
collègues à ses stagiaires ébahis.
 18

Ainsi la notion de support physique, peut rapidement muter en notion de liaison support, ou
de réseau support. Voilà une affaire des plus étranges ! En fait la notion de support va
dépendre un peu de la couche sous laquelle on se place.

Vue des couches 6 et 7, la connexion utilisée est celle de la couche 5, c'est une connexion de
session, pour les couches 7 et 6, le support est là !

De la même manière pour la couche 5, c'est la connexion de transport qui est le support.

Pour la couche 4, c'est la connexion de réseau qui est le support, on parle de réseau support.

Le schéma ci-dessus vous donne une représentation des différents cas. Chaque couche N, se
référé donc à sa couche N-1 en la considérant comme garante de son support de
communication, elle fait abstraction des sous-systèmes qui peuvent aider la couche N-1 à lui
rendre le service de connexion.

CONCLUSION INTERMEDIAIRE
La liaison de donnée n'a maintenant plus aucun secret pour vous. Vous en savez dorénavant
suffisamment pour aborder le détail (façon de parler !) des couches OSI.

LA COUCHE PHYSIQUE
 19

Rôle
Acheminer des EB sur un support de transmission physique.

Les éléments physiques et logiciels concernant les fonctions de cette couche se situent, pour
partie dans le contrôleur de communication du DTE, et pour partie sur la jonction et le DCE.

Même si le rôle paraît simple, croyez bien que les techniques et fonctions à mettre en œuvré
pour envoyer un malheureux "0" ou "1" sur un fil vers l'Australie sont complexes et
nombreuses.

Fonctions
1 - IL FAUT SERIALISER LE SIGNAL !

Vous le savez, les bits à l'intérieur d'un ordinateur se promènent côtes à côtes sur des bus ! Ils se
placent en rang de 8 (il y a longtemps déjà !), de 16, 32 , ou 64 bits (bientôt 128 ou 2012 pourquoi
pas ?!). On dit que la transmission est parallèle. Pourtant vous ne disposerez que de deux fils pour
émettre et recevoir vos données à destination ou en provenance de l'Internet. Il va donc falloir
 20

mettre tout ce petit monde à la queue-leu-leu, en série : sérialiser ! C'est un des rôles du contrôleur
de communication. Autrement dit, les EB qui sont émis sur votre jonction, à la sortie de votre PC, se
suivent les uns derrière les autres, et ne sont absolument pas émis en parallèle. Cette aparté pour
casser certaines croyances parfois bien implantées ! En effet ceux qui disposent d'une jonction sur
câble plat, trouvent souvent qu'elle ressemble à une nappe de bus ... Que nenni, certes il y a
beaucoup de fils, mais ils ne servent pas tous, et les autres ont d'autres fonctions !

2 - IL FAUT SYNCHRONISER LE SIGNAL !

Les bits qui sortent du PC vers le modem sont émis à une certaine vitesse (les grands, diront :
Débit Binaire). Plus vous allez vite, plus la durée d'un bit est courte (logique, puisque aller vite
= grand débit binaire = beaucoup de bits dans peu de temps donc plus le débit est grand, plus
la durée d'un bit est courte !). Cependant, le DTE qui émet sait combien de temps durent ses
EB, mais le modem qui reçoit les bits par la jonction ? Il le sait pas, lui ! Alors on fait comment,
je vous le demande ? Et bien, on synchronise les deux équipements, il existe pour cela deux
techniques :

A. La transmission ASYNCHRONE, dite aussi transmission par caractères, qui consiste à

émettre un START devant chaque caractère envoyé, pour indiquer aux équipements
récepteurs (le modem pour notre exemple) de déclencher leurs horloges internes afin
de lire le caractère qui suit. Un ou plusieurs bits de STOP indiquent à l'horloge que la
lecture du caractère est terminée. En asynchrone chaque équipement possède donc
sa propre horloge interne pour émettre et lire les données. L'horloge émission est
différente de l'horloge réception. ATTENTION, je n'ai pas dit qu'elles n'étaient pas
cadencées à la même vitesse! Elles sont physiquement différentes.

B. La transmission SYNCHRONE, dite aussi transmission par blocs ou trames, dans

laquelle le DTE et le DCE sont reliés par des fils de synchro véhiculant les TOP
Horloges. Dans ce cas un des deux équipements fourni l'horloge à l'autre par
l'intermédiaire des fils. Il faut bien qu'en effet au moins un des équipements soit la
source d'horloge, elle ne se crée pas par l'opération du St Esprit ! L'horloge émission
et réception est donc la même.
 21

3 - IL FAUT GERER LE DIALOGUE ENTRE LE DTE ET LE DCE !

Pour que le DTE puisse émettre des bits vers le DCE, et inversement, il faut qu'ils soient en
liaison

Le DTE n'émettra de plus ses données que s'il est sûr d'avoir un DCE raccordé et sous tension
! Mais faudra-t-il encore que ce DCE l'autorise à lui envoyer des données. De la même manière
le DCE du destinataire devra informer son DTE d'une réception de signal, afin qu'il se prépare
à lire les données.

Nous avons vu précédemment que dans certains cas, le DCE pouvait fournir une horloge au
DTE, et inversement.

Si vous êtes équipé d'un modem Fax- Répondeur, lorsque un correspondant vous appelle
pendant votre absence, votre modem se charge de faire savoir à votre ordintaur qu'il y a un
appel entrant, et qu'il faut qu'il se réveille.

Toutes ses fonctions, et bien d'autres sont réalisées par la jonction. La jonction est ce câble,
que beaucoup prennent pour un bus, qui relie votre modem à votre PC.

Ce câble comporte plusieurs fils qui ont chacun une fonction, un nom et un numéro de broche
sur le connecteur. Ces fils s'activent les uns après les autres selon différentes configurations,
en réponse à des événements. Il existe donc, sur cette jonction, un protocole de
fonctionnement normalisé : une norme fonctionnelle.

Pour indiquer l'activation ou non d'un fil, il faut générer un potentiel. Pour que le DTE et le
DCE se comprennent, il faut qu'ils générent ou qu'ils attendent tous les deux un potentiel de
même valeur. Il existe donc, sur cette jonction, un accord sur la valeur électrique des
potentiels : une norme électrique.
 22

Enfin, vous êtes en complète extase lorsque vous prenez n'importe quelle jonction RS232 (ou
V24) et êtes en mesure de la rentrer sans soucis dans le connecteur de votre PC. Il existe donc,
sur cette jonction, un accord sur la forme du connecteur, son nombre de broches, leur
diamètre, longueur, etc ... : une norme mécanique.

Une jonction est donc au moins définie par 3 normes :

• Des normes fonctionnelles (V24, X24, X20, X21)

• Des normes électriques (V28, V10, V11, V35)
• Des normes mécaniques (ISO-2110, ISO-2593, ISO-4902, ISO-4903)

4 - IL FAUT ADAPTER LE SIGNAL AU SUPPORT !

Le signal électrique véhiculé sur la jonction est appelé signal NRZ (Non Retour à Zéro) et il
posséde un potentiel donné en fonction du type de norme électrique (+/-12V pour une V28,
+/-3V pour une V10 ou V11, etc ...).

Malheureusement, ce signal est totalement incompatible pour une émission en ligne, au bout
de quelques dizaines de mètres, il est tellement affaibli et déformé, qu'on ne peut plus le lire
!

Le DCE a donc pour rôle de transformer ce signal en un autre qui puisse franchir les kilomètres
le séparant d'un prochain point de régénération (un petit coup de remise en forme).

La modulation / démodulation, réalisée par des DCE portant le nom de MoDem (Modulateur-
Demodulateur). Cette technique procède à une transposition du signal de sa bande de
fréquence d'origine dans une bande acceptable par le support. Cette technique est utilisée sur
les supports dits "Analogiques", c'est à dire présentant une bande passante faible, telle que la
 23

bande passante du signal téléphonique (300-3400 Hz). La transmission est dite de type
analogique.

C. Le transcodage réalisé par des DCE portant le nom d'ERBdB (Emetteur/Recepteur

Bande de Base). Cette technique consiste à transformer le signal carré NRZ en un autre
signal carré se véhiculant mieux sur le support. Le signal reste dans sa bande d'origine,
dans sa bande de base, il est simplement transformé, en général pour éviter les
longues suites de "0" et "1", qui se véhiculent très mal sur des supports munis de
tranformateurs de lignes, puisqu'elles s'apparentent à des courants continus.

La couche 1 normalise les techniques de modulation (V23, V22, V22 bis, V32, V34, V34+ et
bientôt V90, etc...), et les techniques de transcodage (Biphase Différentiel, Bipolaire entrelacé
d'ordre 2, HDB3, code de Miller, code Manchester I, code Manchester II, etc ...).

Al'attention des puristes ... Je sais ! Je sais ! Mais que voulez-vous, il faut sacrifier à la
vulgarisation !

Remarques
Au risque de me répéter, je n'ai ici présenté que quelques fonctions associées à quelques
normes, mais il en existe bien d'autres encore, comme : l'adaptation Asynchrone-Synchrone
(V14),

• les normalisations de bouclages et télébouclages (V42),

• les normes d'accès à des réseaux de données publics en mode asynchrone ou synchrone (X20
et X21),
• et puis, et puis, et puis ...

Quoi qu'il en soit, j'espère que ce chapitre vous a fait prendre conscience de quelques
problèmes relevant de la transmission de données à son niveau le plus bas. Nous pouvons
maintenant nous hisser une couche plus haut !
 24

LA COUCHE LIAISON

Rôle de la couche 2

Rôle
Assurer le transfert de blocs de données entre équipements directement connectés avec un
taux d'erreurs résiduelles négligeable.

Le support n'est pas parfait, loin s'en faut ! Il peut se rompre ou générer des erreurs de
transmission, il faut donc le contrôler, c'est le rôle de la couche 2.

Dans cette définition les mots importants sont :

• Blocs de données : qui suppose que la PDU (vous vous souvenez ?) n'est plus un EB,
mais un ensemble d'EB structurés en blocs (un bloc, une trame, une cellule, etc...).
• Equipements directement connectés : car, à un support correspond une et une seule
couche 2, indépendante d'une autre couche 2, qui surveille un autre support. Attention
! Ces deux couches peuvent employer le même protocole, mais il n'y a aucune
interaction entre-elles. (voir schéma ci-contre)
• Taux d'erreurs résiduelles : qui suppose en premier lieu que la couche 2 peut contrôler
les erreurs par un mécanisme du protocole, et; qu'en deuxième lieu il existe un certain
nombre d'erreurs non détectées (les erreurs résiduelles). Il sera dans ce cas possible
de faire d'ultimes contrôles d'erreurs dans les couches supérieures.
 25

Fonctions
1 - Il faut formater une trame (un bloc de données).

La couche 1, nous l'avons vu, véhicule des EB, qui sont les PDUs de niveau 1. Au niveau 2, la
PDU est une trame, une cellule ou un bloc, qui véhicule la PDU de niveau 3 (un paquet) dans
son champ information.

La couche 2, pour réaliser ses fonctions (contrôle d'erreurs, séquencement, contrôle de flux,
etc ...) doit nécessairement possèder dans sa PDU un ou plusieurs champ dans lesquels elle
pourra inscrire ces contrôles (le PCI : Protocol Control Identifier). Souvent un champ spécifique
est réservé pour assurer le contrôle d'erreur.

Il faut aussi pouvoir délimiter le début et la fin d'un bloc d'information (une trame). Il faudra
donc utiliser des délimiteurs (fanions) de début et de fin afin de permettre au récepteur de
répèrer la trame dans le flot de bits de niveau 1 qu'il reçoit.

2 - Il faut assurer la transparence du protocole aux codes de données.

Nous venons d'admettre qu'une trame, pour être repérée par la couche 2 dans le flot binaire
de la couche 1, doit comporter des fanions de début et fin. Ces fanions correspondent
forcément (ou du moins souvent !) à des séquences binaires définies.

Par exemple si la couche 2 détecte une séquence binaire 01110 elle identifiera un fanion de
début (qui peut être le même que celui de fin, d'ailleurs !).
 26

La situation se complique si vous devez absolument transmettre dans vos données une
séquence identique !

La procédure de niveau 2, doit donc mettre en œuvre un mécanisme permettant d'acheminer

cette séquence sans pour autant qu'elle soit prise pour un fanion. La méthode la plus
courante, consiste à insérer un zéro à la suite de toutes séquences de deux 1 consécutifs, que
ces suites soit suivies d'un 0 ou d'un 1. Le récepteur retirera tous les 0 se situant après deux 1
consécutifs. Si les deux 1 sont suivis d'un 1 c'est alors un fanion qui indique la fin de trame (et
le début de la suivante).

Ce mécanisme est communément appelé "la moulinette 7E", car il est utilisé dans les
procédures SDLC d'IBM, HDLC de l'ISO (ainsi que les dérivés comme LAP B, LAP D et même
PPP) sur des séquences 01111110 (7E en hexadécimal) qui sont les fanions.

3 - IL FAUT CONTROLER LES ERREURS DE TRANSMISSION.

Nous avons admis que le support n'était pas parfait. Une connexion à travers le réseau
téléphonique peut-être longue (en distance), elle emprunte beaucoup d'équipements et
parcourt de grandes longueurs de câble. Si lors d'une conversation téléphonique on peut
accepter un taux d'erreur important qui a peu d'incidence sur la qualité de la communication,
il n'en est pas de même pour les transmissions informatiques qui nécessitent une
transmission parfaite de chaque EB. Restituer un 0 pour un 1 transmis peut avoir des
conséquences catastrophiques. Il est donc inconcevable de faire confiance au support de
transmission. Le protocole de niveau 2 mettra donc en oeuvre des mécanismes de contrôle
d'erreurs.

Il existe différents mécanismes de contrôles d'erreurs. Les plus connus sont les VRC, LRC et
CRC, suivis de près par le Checksum.

Le VRC (Vertical Redundancy Code) est réservé aux procédures dites "Orientées Caractères"
fonctionnant sur support asynchrone (si vous avez oublié la notion d'asynchrone : retour à la
page précédente). Une procédure orientée "caractères" est un protocole de niveau 2, qui
 27

utilise une grille de code de caractère (ASCII ou EBCDIC généralement) pour définir les
différents champs d'une trame ou les différentes commandes (connexion, libération,
acquittement, gestion de flux, etc...). Une trame commencera par un caractère STX (Start of
TeXt) et se terminera par un caractère ETX (End of TeXt) de la grille de code ASCII par exemple.
Le VRC propose d'effectuer un contrôle d'erreur caractère par caractère en insérant un bit
supplémentaire au caractère, appelé "Bit de Parité". Le VRC comptera, par exemple, le
nombre de 1 dans le caractère défini sur 7 bits. Si il trouve un nombre impair de 1 il insérera
un huitième bit à la valeur 1 afin d'avoir sur 8 bits un nombre pair de 1. Le récepteur vérifiera
qu'il y a bien un nombre pair de 1 sur un caractère de 8 EB. Si ce n'est pas le cas, il considérera
qu'il y a une erreur sur le caractère et le rejettera. Cette parité peut être de type Paire (EVEN),
Impaire (ODD), Sans parité (NONE), Forcé à 1 (MARK) ou Forcée à 0.

Longitudinal Redondancy Code

Le LRC s'applique aux procédures orientées "caractères" mais en transmission synchrone. Les
données ne sont plus émises caractères par caractères, mais blocs par blocs (ou trames). La
procédure de niveau 2 va stocker dans une mémoire tampon un ensemble de caractères qui
formera un bloc. Caractère par caractère une opération VRC sera appliquée. Puis sur
l'ensemble des bits de parité du bloc et sur l'ensemble de bits des caractères une opération
 28

de parité telle que décrite précédemment sera appliquée. Il en résultera donc un octet
complet qui sera un octet de contrôle d'erreur. Cet octet sera émis à la suite de la trame, on
l'appelle le LRC (Longitudinal Redundancy Code). Le récepteur va stocker la trame dans ses
buffers, recalculer le LRC et le comparer avec le LRC reçu, s'il y a une différence, il y a erreur.

Le CRC (Cyclique Redundancy Check) est une opération mathématique complexe (enfin un
peu ...), que je ne peux pas vous présenter ici. Le principe est d'effectuer une division
polynômiale sur le bloc de données grâce à un polynôme diviseur appelé : "Polynôme
Générateur". Cette division donne en résultat un reste qui est émis à la suite de la trame sur
le support. Le choix du polynôme générateur déterminera la taille maximum des trames qu'il
sera possible de contrôler ainsi que la taille du reste. Ce reste est placé à la fin de la trame et
est appelé le CRC4, CRC8, CRC16 ou CRC32 selon le nombre de bits qui lui est réservé. Les
trames HDLC, PPP, LLC utilisent des CRC16. Les trames sur réseau local utilisent des CRC32.

Le CRC effectue des opérations au niveau bit, il est donc utilisé sur des procédures "Orientées
Bits". C'est à dire des procédures dont la valeur d'un seul EB dans une trame peut être
interprété et être significatif pour le protocole. La procédure n'utilise donc pas des caractères
pour structurer ses champs mais des nombres variables de bits.

Chacun de ces contrôles d'erreurs possède ses limites en détection d'erreurs. Le VRC sera par
exemple incapable de détecter une erreur si deux bits ont changé dans le caractère, le LRC ne
détectera pas les erreurs simultanées sur des bits en quadrature (formant un carré) dans le
bloc. Le CRC est beaucoup plus fiable mais n'est pas infaillible non plus. Il existe donc des
erreurs qui ne sont pas détectées, c'est le taux d'erreurs résiduelles. Il relèvera des couches
supérieures d'effectuer un nouveau contrôle (généralement en couche 4).

4 - IL FAUT GERER LE DIALOGUE.

Le protocole de niveau 2 est un dialogue qui s'établi entre deux équipements séparés par un
support. Comme dans la vie courante, il existe deux modes essentiels de partage de
l'information orale, le mode dirigé et le mode libre.

A. Dans le mode dirigé, c'est comme à l'école ! Il y a un maître et un esclave (oui, oui, je
sais ! Un élève ! Mais j'ai gardé de mauvais souvenirs ...). L'esclave parle quand le
maître l'y autorise. A l'école, le maître voit qu'un élève lève le doigt. En
téléinformatique ça ne peut pas marcher comme ça, puisque le maître n'a pas d'yeux
! (NDLR: Elle est bien bonne celle-là !). En fait le maître va envoyer à l'esclave (ou aux
esclaves) des invitations à émettre. Ces invitations sont communément appelées des
POLLING. L'esclave répondra par une émission de données ou par "Rien à émettre,
CHEF !!!". Le maître est tout de même légérement civilisé, ainsi lorsqu'il a quelque
chose à dire à l'esclave, il le prévient par un SELECTING. Bien sûr l'esclave n'a pas le
choix, il reçoit ! C'est ça la démocratie ! En bref, l'esclave se tait tant que le maître ne
l'a pas autorisé à parler, les procèdures fonctionnant sous ce mode sont dites "Non
Equilibrées", dans le sens ou la répartition de faculté à prendre l'initiative d'un
dialogue n'est pas équilibrée. En Anglais on dit : Unbalanced. La procèdure VIP de BULL
est une procédure non-équilibrée fonctionnant en mode caractère (un dinosaure, quoi
!).
 29

B. Dans le mode libre (et non pas "Le Monde Libre"), c'est comme à l'assemblée nationale
! Chaque extrémité peut prendre la parole quand bon lui semble (quand elle a quelque
chose à dire, pas comme à l'assemblée nationale !). Les équipements doivent donc être
capable d'écouter en même temps qu'ils parlent (ce qui n'est pas à la portée du
premier venu, et surtout pas de nos députés ...). Ces procédures sont extrêmement
rentables en terme de capacités de transmission car elles évitent les temps morts
pendant lesquels un esclave doit se taire ! Elles présentent par contre l'inconvénient
de nécessiter des mécanismes de gestion du dialogue beaucoup plus complexes (hors
de portée de nos députés ...). Ce mode est démocratique, égalitaire, il est "Equilibré"
(moralement aussi, ce qui n'est pas toujours le cas de ...)

La mode est plutôt à la procédure équilibrée et orientée bit ! (L'idéal pour un député, quoi !).

Remarques
Encore une fois, cette page ne vous présente que quatres malheureuses fonctions de la
couche 2, pourtant il en existe bien d'autres :

• la correction d'erreurs (car nous n'avons parlé ici que de détection d'erreurs),
• le contrôle de flux,
• l'adressage,
• la gestion d'accès au support (le MAC pour les fins connaisseurs),
• la gestion de connexion,
• et puis, et puis ...

Vous avez toujours une meilleure idée du rôle de ce satané protocole PPP que l'on voit
apparaître dans l'onglet "Serveur" des propriétés de connexion sur l'icône d'accès à distance
à Wanadoo. Ci-dessous quelques noms de procédures :

• PPP : Point to Point Protocol : Protocole non ISO, mais défini par l'IETF sous une RFC,
permettant l'acheminement du protocole IP (et d'autres) sur un lien série en communication
synchrone ou asynchrone, équilibrée ou non, et offrant nombre de services tels que
l'authentification d'accès.
• HDLC : High level Data Link Control : Protocole de niveau 2 très élaboré normalisé ISO. Nombre
d'autres protocoles prennent leur source dans cette gigantesque boîte à outils. Ainsi le LAP-B
utilisé pour les accès à un réseau X25 ou le LAP-D, utilisé pour la signalisation sur le canal D
Numéris sont-ils directement issus de ce protocole.
• LLC (1,2 ou 3) : Logical Link Control : Protocoles normalisés ISO s'inspirant fortement d'HDLC.
Ils définissent des champs d'adressages évolués et des niveaux de services différents en
fonction du type de procédure LLC. Avec ou sans connexion, avec ou sans acquittement, avec
ou sans gestion de flux etc... Ils sont très utilisés en environnement réseau local.
• SDLC : Synchronous Data Link Control : La maman d'HDLC. Développée par IBM, cette
procédure permet de gérer des dialogues synchrones en mode équilibré ou non, avec un ou
plusieurs équipements simultanés à travers de nombreux types de supports (RTC, Liaisons
Louées, etc...). HDLC est très fortement inspiré de SDLC, et merci IBM.
• DLC : Data Link Control : La grand-mère d'HDLC ou la maman de SDLC si vous préférez ! Le papa
c'est bien sûr IBM !
 30

Si la couche 3 vous a toujours intriguée, si l'utilité d'un protocole comme IP ou X25 vous
semble nébuleuse ... Suivez-moi !

La couche réseau
Rôle
Offrir les moyens d'accéder à un réseau et les procédures pour acheminer les données à
travers un réseau.

Un groupe d'utilisateurs forment souvent ce que l'on appelle "un réseau de connaissances",
ils sont liés par un ensemble d'intérêts communs. Pour s'échanger les informations qui les
concernent ils utilisent un ensemble de protocoles standardisés qui définissent à la fois la
manière dont les informations doivent être présentées, et les méthodes utilisées pour
acheminer les informations dans le groupe jusqu'aux destinataires. C'est exactement le rôle
de la couche réseau du modèle OSI. Le protocole de présentation est en fait la procédure
standardisée d'accès au réseau tandis que la manière d'acheminer les informations dans le
groupe représente l'ensemble des procédures standardisées pour acheminer l'information
dans le réseau.

Les types de réseaux informatiques sont multiples et les procédures ou protocoles sont
nombreux. Les plus connus restant cependant le X25 (X25.3 ou X25 PLP pour les puristes) et
IP, le petit chéri de nous autres Internautes ! Quoiqu'il en soit la représentation ISO reste
valable dans tous les cas :

L'unité de données du protocole est appelée la NPDU (Network Protocol Data Unit) plus
connue sous les noms de "paquets" ou "datagrammes". Cette NPDU est encapsulée dans la
LPDU du niveau 2.

Le schéma ci-dessus présente un acheminement d'un paquet de niveau 3 à travers un

commutateur entre deux stations clientes d'un réseau. Le réseau est ici ramené à sa portion
la plus congrue, un seul commutateur. A noter qu'un routeur présentera le même rôle, mais
la ressemblance s'arrête là. Nous aurons sans doute un jour l'occasion de longuement exposer
la différence entre un routeur et un commutateur. Vous noterez dans ce schéma que les
couches 2 peuvent utiliser des protocoles différents de chaque coté du commutateur
 31

(protocoles X et Y), mais que le niveau 3 utilise le même protocole (protocole Z), à travers tout
le réseau, de station à station. Rappelez-vous la règle d'homogénéité du modèle OSI ! A un
moment donné il faut forcément parler la même langue si l'on veut se comprendre !

Fonctions
1 - IL FAUT (OU NE FAUT PAS) ETABLIR UNE CONNEXION.

Pour acheminer les données dans un réseau, il existe deux politiques majeures. Etablir au
préalable à la transmission, une connexion avec le correspondant, ou émettre les données
sans se soucier de savoir si le correspondant est présent.

Une analogie simple est la suivante : Un jour, au bureau, vous avez besoin d'un dossier. Vous
criez à votre collègue Jacques qui est derrière une paroi et que vous ne voyez pas : "Jacques
apporte-moi le dossier DuGenou s'il te plaît !". Et vous attendez que Jacques vous l'apporte.
Vous venez de faire un transfert d'information en mode non connecté, vous n'avez pas vérifié
la présence de Jacques, alors qu'il est peut-être au toilette depuis une heure à lire Play-Boy !
Vous n'êtes absolument pas sur de l'avoir contacté ! S'il vous dit qu'il n'a pas entendu, vous
ne pourrez pas le frapper ! La deuxième méthode est de dire : "Jacques t'es là ??". Si Jacques
répond "Oui !", il est foutu car vous allez lui demander le dossier et il sera obligé de vous
l'amener (s'il veut son chèque à la fin du mois). Vous avez fonctionné en mode connecté, vous
avez vérifié au préalable à la transmission, la présence du correspondant.

En mode connecté, vous établissez un canal (physique ou virtuel). Les informations sont
émises sur ce canal de manière séquentielle, l'ordre de réception étant forcément le même
qu'en émission. La perte d'une information se traduit par une remise à zéro du circuit, voir
une déconnexion. Ce mode suppose une procédure de gestion de la communication assez
lourde qui en diminue le rendement. Par contre le service réseau rendu aux couches
supérieures est suffisamment fiable pour nécessiter un minimum de contrôle au niveau de la
couche transport. Le mode connecté était le mode privilégié de fonctionnement des réseaux
longues distances avant l'intronisation d'IP.

Le circuit physique : Ce type de réseau est dit à commutation de niveau 1. C'est la couche
physique qui assure la mise en relation. La connexion peut être assurée par relais comme dans
l'ancien RTC (type CrossBar) ou par commutation d'IT comme le RTC actuel (MT25). Dans
d'autres cas on parlera aussi de réseau physique à commutation lente pour indiquer des
 32

réseaux non pas commutés mais brassés. C'est à dire des réseaux sur lesquels on programme
à la demande des relations entre IT afin de créer des circuits fixes. L'utilisateur n'a pas à gérer
de procédure d'établissement de communication physique.

Le circuit virtuel : ne relève pas de la couche 1. C'est un circuit de niveau supérieur géré par
une procédure.

Le principe consiste à appliquer un numéro logique à chaque PDU (inscrit dans une en-tête de
PDU). Toutes les PDU comportant le même numéro sont émises vers le même destinataire.

Un même accès physique peut ainsi gérer plusieurs connexions virtuelles en affectant des
numéros différents aux PDU en fonction de leur destination. Il conviendra bien sûr d'être en
totale cohérence avec l'accès réseau, afin que l'acheminement soit correct.

Il existe principalement deux types de connexions virtuelles :

Les connexions permanentes (CVP, PVC en X25 ou Frame Relay, VP en ATM), qui
correspondent à la notion de brassage ou commutation lente définie précédemment. Les
connexions dans le réseau sont crées à la mise en œuvre du réseau et restent figées.
L'utilisateur n'a pas à gérer l'établissement d'une connexion, elle est déjà établie.

Les connexions commutées (CVC en X25, bientôt disponible en Frame Relay, VC en ATM bien
qu'actuellement le niveau VC soit toujours brassé). L'utilisateur doit dans un premier temps
généré une demande de connexion en spécifiant le destinataire (adressage). Le protocole crée
une route dans le réseau et vérifie l'accessibilité et la disponibilité du destinataire. Si la
connexion est positive le réseau réserve les ressources qui seront figées jusqu'à la fin de la
communication.

En mode non connecté, vous n'établissez pas de circuits. Vous livrez, au réseau, un
datagramme (paquet comportant toutes les informations nécessaires à son routage
(@source, @destination)), il s'occupe alors de l'acheminer par le chemin qui lui semble le
meilleur (notion de gestion dynamique du routage). Ainsi deux datagrammes, émis à peu de
temps d'intervalles, pour le même correspondant n'emprunteront pas forcément le même
chemin. Ils n'auront donc pas forcément le même délai de transit, à l'inverse des réseaux à
 33

commutation de circuits. Il se peut aussi, qu'un datagramme 2 arrive avant le premier car il
aura été acheminé sur une route plus rapide ! Le séquencement de l'émission n'est donc pas
forcément respecté en réception, le rôle de la couche transport sera de palier à ce problème.

Enfin, souvent, un datagramme a une durée de vie, fixée par son émetteur, au bout de laquelle
le réseau le détruit, il y a donc des risques de pertes d'informations que la couche 4 doit aussi
être en mesure de gérer. Ce mode de fonctionnement jusqu'ici réservé à des réseaux
présentant des topologies fiables et de courtes distances, a tendance à se généraliser même
sur les réseaux longues distances. Il offre en effet un excellent rendement puisqu'il suppose
un minimum de gestion, ainsi qu'un minimum de ressources réseaux.

L'adressage

2 - IL FAUT GERER UN FORMAT D'ADRESSE.

Il tombe sous le sens, que dans un réseau les utilisateurs sont multiples. Lorsqu'une donnée
est émise il est donc impératif que le réseau soit en mesure d'identifier le destinataire. Il est
alors nécessaire d'utiliser une adresse (Rappelez-vous l'analogie avec la Poste).
 34

Le protocole de niveau 3 OSI, devra donc prévoir dans l'en-tête de sa PDU un champ adresse.
En fonction du réseau utilisé, le protocole diffère et bien souvent le format d'adresse aussi.

Il est à noter que si on utilise un réseau fonctionnant en mode connecté (X25), il n'est pas utile
de spécifier l'adresse destintaire dans chaque paquet. Dans le cas d'un réseau à circuits
virtuels, une fois le circuit activé il suffit d'indiquer son numéro (voir ci-dessus). On utilise dans
ce cas plusieurs formats distincts de paquets : un paquet d'appel qui trace la route et réserve
les ressources dans le réseau, ce paquet comporte l'adresse. Et un paquet de données qui ne
comporte que les données et un numéro de voie logique (circuit).

Dans le cas des réseaux en mode non connecté (IP), tous les paquets ont le même format. Ils
comportent l'adresse destinataire et les données

Segmentation

3 - IL FAUT POUVOIR GERER UNE FRAGMENTATION.

Tous les paquets de niveau 3 (NPDU) sont placés dans le champ DATA des trames de niveau 2
(LPDU).

Une trame possède très souvent une limite de longueur pour son champ information. Cette
limite peut être fixée par respect de contraintes comme le type de contrôle d'erreur utilisé, la
taille des buffers nécessaires pour mémoriser les trames, le nombre de trames émises avant
attente d'acquittement, etc ... Quoi qu'il en soit la champ information possède une limite de
taille appelée MTU : Maximum Transmission Unit.

Si un paquet possède une taille supérieure à cette MTU il faudra le tronçonner et l'émettre
dans plusieurs LPDU consécutives. Cette opération est appelée la fragmentation ou
segmentation.
 35

Le protocole de niveau 3 devra prévoir des mécanismes et des champs dans ses NPDU
permettant de mettre en oeuvre cette fonction. Il faudra aussi qu'il soit capable en arrivée
d'effectuer l'opération de "recollement" des paquets fragmentés, appelée "concaténation".

4 - IL FAUT POUVOIR GERER DES PRIORITES D'ACHEMINEMENT.

Lorsque nous aurons progressé dans les mécanismes de réseaux, nous verrons que certains
équipements de réseaux, comme les routeurs, peuvent être multi-protocoles. C'est à dire
qu'ils sont capables d'acheminer simultanément différents protocoles de niveau 3 (IP et X25
par exemple).

L'utilisateur aura alors peut-être besoin de prioriser l'acheminement d'un protocole par
rapport à un autre. Ce sont les équipements routeurs qui auront en charge cette fonction.
Cependant ce mécanisme ne relève pas des fonctions d'un protocole, mais des fonctions d'un
équipement.

Par contre, au sein d'un même protocole, il peut être nécessaire d'acheminer en priorité
certains paquets par rapport à d'autres. Il est alors nécessaire que le protocole prévoit dans
ses NPDU des champs permettant d'indiquer le niveau de priorité du paquet. Les équipements
du réseau (commutateur ou routeurs) en analysant l'entête du paquet pourront détecter ce
niveau de priorité et enclencher un mécanisme d'acheminement prioritaire (route rapide, pas
de mise en buffer d'attente, etc...).

IP prévoit cette fonction grâce son champ TOS : Type Of Service dans son entête.

Remarques
Encore une fois, je n'ai ici présenté que quelques fonctions mises en oeuvre par des protocoles
de niveau 3, mais il en existe d'autres comme :
 36

• la gestion de flux,
• le contrôle d'erreur,
• etc...

Il est important de noter que la majorité des fonctions présentées dans ce chapitre ne sont
pas spécifiques à la couche réseau. Ainsi la question de connexion ou non connexion se pose
de la couche 1 à la couche 5. Il en est de même pour l'adressage, le contrôle de flux, la
segmentation ou encore le contrôle d'erreur. Chaque couche utilise souvent toute ou partie
de ses fonctions. Ce n'est pas un problème de redondance, car en fait selon la couche la
fonction n'aura pas la même portée fonctionnelle ou géographique.

Ainsi la couche 4 suivante présente-elle nombre de fonctions présentées ici, mais la portée
géographique et fonctionnelle est différente. Si l'utilité d'un protocole comme TCP vous
semble des plus flous. Suivez-moi !

la couche Transport

Rôle
Assurer le contrôle de bout en bout, de processus à processus, à travers les réseaux et sous-
réseaux empruntés.

Nous avons vu, précédemment, qu'une communication à travers un réseau (couche 3) pouvait
s'établir en mode connecté ou pas. Que la couche 2 pouvait laissé passer des erreurs de
transmissions (taux d'erreurs résiduels) ou que le contrôle de flux n'était pas obligatoirement
réalisé au niveau réseau. Ces quelques fonctions peuvent cependant être nécessaires à un bon
échange entre entités informatiques. La couche Transport permet donc de les mettre en
oeuvre (mais ce n'est pas obligatoire).

La couche 4 est souvent considérée comme une couche d'interface entre le domaine
informatique dont les couches 5, 6 et 7 relèvent plutôt, et le domaine téléinformatique (dit
sous-réseau de transport) que sont les couches 1, 2, 3 et partiellement 4. La couche 4 ne se
contente plus de gérer la communication, elle permet de mettre en relation deux processus
distincts entre deux machines. Nous aborderons cette notion dans les fonctions suivantes.
 37

L'unité de données du protocole est appelée la TPDU (Transport Protocol Data Unit) plus
connue sous les noms de "segments" ou "paquets". Cette TPDU est encapsulée dans la NPDU
du niveau 3.

Le schéma ci-dessus présente un acheminement d'un segment de niveau 4 à travers un réseau

unique. Ce réseau de transport de niveau 3 pourrait être un enchaînement successif de
différents réseaux (réseaux X25 puis IP et de nouveau X25 par exemple). La couche 4 n'en
serait pas moins unique est homogène ! Rappelez-vous la règle d'homogénéité du modèle
OSI !

A l'attention des puristes : il est vrai qu'un enchaînement de réseaux X25 puis IP, obligera à
quelques manipulations supplémentaires ... Mais ne compliquons pas s'il vous plaît !

Multiplexage de connexion Niveau 4

Fonctions
1 - Connexions entre processus

Il peut arriver (et même souvent), qu'un même programme entre deux machines (par exemple
un Browser vers un serveur WEB) soit dans l'obligation de mettre en relation plusieurs
processus simultanément. Ainsi le dialogue entre les deux machines utilise un même parcours
réseau (ou connexion réseau), mais sur cette seule est unique relation de niveau 3 entre deux
uniques machines, on pourrait avoir plusieurs connexions de niveau 4, accomplissant
chacune une tâche (un processus) distincte. L'exemple le plus parlant peut se trouver sur le
WEB :

Lorsque vous vous connectez à un serveur WEB, vous empruntez dans le réseau Internet une
route vous reliant au serveur, grâce au protocole IP (couche 3). Il existe une seule relation de
niveau 3 entre l'adresse IP de votre PC et l'adresse IP du serveur. IP étant en mode non
connecté vous pouvez éventuellement emprunter des routes différentes en fonction de la
charge et de l'état du réseau. Mais la relation de niveau 3 (@source-@destination) n'en est
pas moins unique.
 38

En supposant que la page que vous téléchargez comporte un texte et deux images. Vous
établirez une connexion de couche 4 (couche TCP ici) pour le transfert du texte, et une
connexion pour chaque image, soit au total trois connexions. Chacune sera régie par son
propre contrôle d'erreur, sa propre gestion de flux, ses propres timers. Chacune est
indépendante de l'autre, alors qu'elles sont toutes véhiculées par la même connexion réseau.
Vous pouvez d'ailleurs pressentir cette indépendance lorsque vous recevez le texte
immédiatement et que les images pourtant placées en entête vous parviennent plus tard (ou
même carrément jamais !).

On parle dans ce cas de multiplexage de connexion de niveau 4, sur une connexion de niveau
3. Dans l'absolu, cela voudrait dire qu'une NPDU (PDU de niveau 3), pourrait véhiculer
simultanément plusieurs TPDU. Dans la pratique ce n'est jamais le cas, une NPDU véhicule une
seule TPDU. En effet, de toute manière, dans la plupart des cas, le segment (TPDU) est de taille
supérieure au paquet (NPDU).

La Gestion de Flux

2 - LE CONTROLE DE FLUX.

Le contrôle de flux est la technique qui consiste à donner la possibilité à un récepteur, quand
il est surchargé, d'interrompre le flux de données de l'émetteur. Le sujet est particulièrement
vaste, car la gestion de flux peut-être implémentée au niveaux 1, 2, 3, 4 et 5. Rien que ça !
Cependant selon le niveau où on la trouvera, elle n'aura pas la même portée, ainsi :

Une gestion de flux de niveau 1 ou 2, ne régule le flux qu'entre deux équipements adjacents
(séparés par un support, rappelez-vous la définition de la couche 2).

• Une gestion de flux de couche 3 régulera le flux entre des équipements de réseaux
(commutateurs, commutateurs-stations clientes), ou entre machine d'extrémité du
réseau (les deux machines clientes en relation)
• Une gestion de flux de niveau 4, régule les flux de chaque connexion de niveau 4
établie entre deux machines. Ainsi dans l'exemple précédent, il sera peut-être
nécessaire de réguler le flux de transfert de la page texte, par contre le serveur étant
 39

surchargé n'est pas en mesure d'acheminer les images plus vite que le récepteur, il
n'est donc pas nécessaire de réguler le flux des images.

Les techniques de gestion de flux sont nombreuses mais quelques unes sortent du lot :

• Au niveau 1, on trouvera la gestion de flux par fils de jonctions (RTS et DTR) appelée
aussi gestion par 105 ou 108. Cette technique ne peut être mise en oeuvre qu'entre
des équipements séparés par un support au plus, ou directement raccordés par une
jonction.
• Lorsque la transmission est en mode caractère (asynchrone) on utilise généralement
la technique du XON/XOFF qui sont deux caractères de la grille ASCII. Le XOFF est émis
par le récepteur vers l'émetteur pour stopper la transmission, le XON pour la relancer.
Des querelles de clocher se font jour entre puristes pour classer ce mode en niveau 1 ou
2 de l'OSI. Je n'ai pour ma part pas d'avis (avec un penchant pour le niveau 1 quand
même !).
• Au niveau 2 on trouve essentiellement le mode de gestion par fenêtrage. Qui consiste
à laisser la possibilité à l'émetteur d'émettre un nombre défini de trames sans recevoir
d'acquittement. Le nombre en question défini la fenêtre d'anticipation
autorisée.Lorsque l'émetteur à émis toute la fenêtre autorisée il s'arrête jusqu'à
réception d'une trame d'acquittement lui réouvrant sa fenêtre. C'est la méthode
utilisée dans les procédures découlant d'HDLC.
• Au niveau 3 on peut utiliser la même technique. En X25 la gestion de flux est dite de
proche en proche. A savoir que la fermeture de fenêtre va progressivement remonter
du destinaire final vers son commutateur de rattachement, puis vers les commutateurs
de transit, puis le commutauteur de rattachement de l'émetteur, pour enfin aboutir à
l'émetteur. Chaque équipement aura utilisé les possibilités de fenêtres et le réseau
aura donc finalement bufférisé un certain nombre de paquets.
• En IP la gestion de flux est assurée par un protocole annexe dénommé ICMP. Par des
paquets appelés "Source Quench", l'équipement surchargé peut demander à
l'émetteur de temporiser ces émissions, mais pas de les stopper. C'est un frein, pas un
stop !
• Au niveau 4, la technique de fenêtre d'anticipation est aussi utilisée. En TCP la
technique retenue consiste à ouvrir une fenêtre en nombre d'octets. Lors d'un
acquittement le récepteur indique à l'émetteur combien d'octets il peut lui émettre.

Nous venons ici de brosser sommairement quelques techniques de gestion de flux. Le sujet
est très vaste et pourrait largement justifier d'un chapitre spécifique (voir un livre !). Mais je
ne dispose ni du temps, ni de la place, ni du courage !

Remarques
Je n'ai ici présenté que deux fonctions nouvelles. Ne croyez pas que ce sont les seules mises
en oeuvre par les protocoles de couche 4. Ce n'est pas non plus que mon ardeur diminue
(quoique !). Mais nous avons déjà vu les fonctions de contrôles d'erreurs et de connexions qui
en plus de la gestion de flux sont les grandes fonctions des protocoles de couche 4.Vous avez
 40

pu remarquer que finalement on retrouve souvent les mêmes fonctions d'une couche à
l'autre. Mais ce n'est pas vraiment une redondance, car la portée de chaque protocole est
différente. Les niveaux 1 et 2 n'influent que sur des équipements adjacents, le niveau 3 sur
des équipements partageant une connexion réseau, le niveau 4 remonte jusqu'au process.

Encore une fois, je n'ai ici présenté que quelques fonctions mises en œuvre par des protocoles
de niveau 4, mais il en existe d'autres comme :

• l'adressage de process (port ou socket),

• le contrôle d'erreur (sur segment complet ou sur entête),
• la segmentation de TPDU (optimisation de l'utilisation de la MTU du niveau 3),
• etc ...

Nous quittons dorénavant le domaine du transport de l'information, pour entrer dans un

domaine un peu plus informatique. La couche 4 était une frontière dans le sens où pour une
part elle gère des notions de contrôle d'erreurs, de gestion de flux et s'appuie sur un réseau
de transport de l'information, et que d'autre part elle connecte et gère des process
informatiques. Ainsi l'ensemble des couches 1 à 4 est-il vu par les informaticiens comme le
sous-réseau de transport.

Les couches 5 et 6, sont très facultatives, et, pour tout dire, il est très difficile de les situer dans
les environnements constructeurs actuels. En effet, nombre de leurs fonctions sont gérées
directement par les applications et elles ne peuvent donc justifier leurs existences. Ainsi
l'architecture IP passe directement d'un équivalent de couche 4 (TCP) à un équivalent de
couche 7 (FTP, HTTP, SMTP, etc...).

Le chapitre suivant vous présente donc très sommairement la couche Session.

La couche Session

Le chef d'orchestre !

Rôle
Gérer le dialogue entre les entités applicatives.
 41

Nous avons vu, précédemment, que la couche 4 permettait de gérer le contrôle de connexion
entre process applicatifs. La couche session a le rôle plus ambigu, d'organiser le dialogue. C'est
en quelque sorte le chef d'orchestre d'une relation entre processus applicatifs. Elle va
regrouper des tâches, s'assurer qu'elles sont réalisées en posant des jalons dans la
transmission, elle assurera enfin le partage équitable de la parole ! Démocratique la couche 5
! C'est sans doute pour cela qu'on ne la trouve que très rarement implémentée dans les
architectures informatiques !

En effet, ses fonctions sont tellement proches des préoccupations informatiques

(applicatives), qu'elles sont bien souvent prises en charge par l'application elle-même, et donc
difficilement discernable comme entité propre ! Ainsi l'architecture TCP-IP ne comporte pas
d'équivalent de couche 5 !

L'unité de donnée du protocole est appelée la SPDU (Session Protocol Data Unit). Cette SPDU
est encapsulée dans la TPDU du niveau 4.

M. Session organise le dialogue !

Fonctions
1 - Gestion du dialogue

Je vous disais que la couche 5 était assez rarement implémentée, c'est bien le cas ! Surtout à
l'assemblée nationale ! Pourtant la fonction de gestion du dialogue y serait bien utile. Cette
fonction a pour rôle de gérer l'attribution de la parole à chaque entité applicative à tour de
rôle par délivrance d'un jeton. Seule l'entité applicative possédant le jeton a le droit de
prendre l'initiative d'un travail. Pas comme chez nos députés qui se jettent à coeur joie dans
des débats aussi tonitruants et impétueux qu'inorganisés et séniles ! Je plaisante ... Je les
adore !!

La transmission du jeton pourra se faire selon le cas sur des critères de durée de parole (le
plus courant), de séquencement d'opérations, voir de volume de transaction (très rare !).
 42

vive les points de reprise !

2 - LA SYNCHRONISATION DU DIALOGUE.

Imaginez votre déconfiture lorsqu'un transfert de 10 Mo est sur le point de se terminer et

qu'une coupure réseau, que n'a pas pu rattraper la couche 4, vient interrompre le travail en
cours ! Une heure de boulot, à l'eau ! (Je hais les Télécoms !! Quand nous livreront-ils des liens
parfaits ?). Si vous avez déjà réalisé des transferts FTP sur Internet il y a quelques années, vous
savez de quoi je parle, n'est-ce pas ?

Heureusement, une évolution du protocole FTP a permis de reprendre un téléchargement à

l'endroit où il a été interrompu. Il n'est plus nécessaire de le reprendre au début. Mais à
l'époque, il était normal (ou presque !) que nous perdions tout le télécharge mènent en cas
de coupure réseau, car TCP-IP n'a pas de couche session !! Avec une vraie couche session de
chez SESSION & Co, il y aurait eu un jalonnement du transfert de fichier en instaurant des
points de reprises.

Tous les 2 Mo par exemple, l'émetteur se serait arrêté et se serait assuré auprès du
destinataire de la bonne réception. Si dans un train de 2 Mo il y avait un problème, la couche
session aurait lancé une reprise à partir des derniers 2 Mo validés ! En non depuis le début !!

Remarque : Actuellement, FTP simule ce principe en mémorisant le nombre d'octets

téléchargés. Il conserve cette information en cache sur votre disque dur, en l'associant à l'URL
du fichier téléchargé. De cette manière vous pouvez même reprendre votre téléchargement
plusieurs jours après. Si l'information n'a pas été écrasée en cache, FTP va simuler un
téléchargement des premiers octets déjà chargé et attaquera le réel téléchargement à
l'endroit où il a été interrompu.
 43

La séparation en activités

3 - L'ORGANISATION DU DIALOGUE.

Une relation à distance (on fait de la téléinformatique ici, Monsieur ! On travaille à distance,
pas à deux mètres de son ordinateur !), entre applications peut revêtir de nombreuses formes.
Les opérations peuvent être de la saisie de données dans des masques, un lancement
d'impression, une sauvegarde sur disque, etc...

Pire ! Une relation entre entités applicatives peut cumuler plusieurs de ces tâches
consécutivement ! Voir même simultanément ! La couche session va donc organiser sur la
connexion de couche 4, la séparation en activités qui seront généralement séquencées dans
le temps. Ainsi on commencera peut-être par une saisie dans un masque, suivie d'une
impression du résultat sur un imprimante proche de l'opérateur et d'une sauvegarde des
données dans la base !

Chaque activité aura donné lieu à un point de reprise majeur, qui jalonne le début et la fin
d'une activité ! Sachant que le point de reprise mineur quand à lui assure la synchronisation
du dialogue comme vu précédemment !

Remarques
Je vous avez prévenu ! Cette page est sommaire ! Les couches 5 à 7, sortent sérieusement du
domaine purement téléinformatique ! Jusqu'à peu, elles étaient systématiquement noyées
dans le code source applicatif. Petit à petit on voit beaucoup émerger la couche 7 mais les
couches 5 et 6 restent encore très virtuelles ! La couche 5 ne trouve sa place que dans des
architectures résolument orientées "Connexion" comme SNA d'IBM ou DNA en DecNet Phase
V de DEC (Digital Equipment Corporation).
 44

La couche Présentation

Rôle
Assure l'adaptation des données entre les systèmes hétérogènes - Gère la représentation
des données.

Le modèle OSI est conçu pour faciliter l'interconnexion de systèmes ouverts ! Mais ces
systèmes sont bien souvent hétérogènes, ils utilisent d'ailleurs bien souvent des modèles de
représentation des données qui sont différents. Par exemple les uns utiliseront un codage
EBCDIC (notamment chez IBM) et d'autre un codage ASCII (notamment en UNIX) pour réaliser
le codage d'une grille de caractère !

Pour certains systèmes il faudra de plus implémenter un système de cryptage des données
(notamment dans le cas des applications de traitements bancaires ou même pour le
Télécommerce sur Internet !).

La couche présentation assure ces fonctions.

L'unité de données du protocole est appelée la PPDU (Presentation Protocol Data Unit). Cette
PPDU est bien sûr, en principe, encapsulée dans la SPDU du niveau 5.

Négociation

fonctions
1 - NEGOCIATION DE SYNTAXE DE TRANSFERT

Imaginons trois Internautes : un anglais, un français et un grec (pourquoi pas ?). Un soir ils se
rencontrent sur un "chat-room" (pour faire dans l'air du temps !). Aucun d'entre-deux ne sait
parler la langue de l'autre, et pourtant ils aimeraient communiquer !
 45

Première solution : L'anglais, peu avare, téléphone à une boite d'intérim et commande deux
traducteurs. Lorsqu'il veut parler au français il active son traducteur français, lorsqu'il veut
parler au grec, il active son traducteur grec ! Vous imaginez sans peine la joie de l'agence
d'intérim lorsque l'anglais décide de converser avec des autochtones de dix nations
différentes !

Deuxième solution : Le français, plus avisé (bien sûr) dans ses dépenses (plus avare quoi !),
décide de n'engager qu'un seul traducteur ! Il dit : "Moi je veux un traducteur en Espéranto !
Il traduira mon bon français des chaumières en un pur Espéranto que les autres devront
comprendre et eux-mêmes traduire dans leur dialecte incompréhensible !". Avisé, le français,
a ainsi réparti les coûts de traduction sur les différents communicants ! De plus quiconque
voudra participer à la discussion devra se procurer un seul traducteur Espéranto (le cours du
traducteur Espéranto est à la hausse ... Métier d'avenir !).

Troisième solution : Le grec, cherche toujours ! (Ce que je peux être méchant quelques fois !).

Le modèle OSI propose d'appliquer la solution 2, mais laisse aussi toute latitude pour se
rabattre sur la première solution ... Je m'explique :

Dans le cas 1, deux entités ne parlant pas le même langage, pourront tenter de négocier
l'utilisation d'un langage commun. Par exemple, si A parle nativement en A, et B parle
nativement en B. A dit à B : " Moi je sais parler en A et C. Et toi ? ", B répond : " Moi je parle
en A et B. Parlons donc en A, OK ?". A répond : "OK". Négociation terminée !

La couche présentation propose, par son protocole, la négociation de langages de transfert.

Dans le cas 2, deux entités ne parlant pas le même langage pourront négocier une syntaxe de
transfert commune. Par exemple, si A parle nativement en A, mais dispose d'une couche
présentation proposant un langage C, et B parle nativement en B mais dispose également
d'une couche présentation proposant un langage C. A dit à B : " Moi je sais parler en A etC. Et
toi ? ", B répond : " Moi je parle en C et B, on parle donc en C, OK ?", A répond : "OK".
Négociation terminée !

On remarque ici que le langage choisi n'est aucun des deux langages natifs. C'est un choix de
langage de transfert ! A va traduire sa syntaxe A en C, l'émettre, B en réception traduit C en B,
et le tour est joué ! Enfin presque ...

L'ASN 1

2 - UNE SYNTAXE DE TRANSFERT A TOUTE EPREUVE

 46

Le paragraphe précédent présente les négociations de manière idyllique ! En effet, on peut

facilement imaginer que pour certains mots il n'y ait pas d'équivalent d'un langage à un autre
! Ainsi certains caractères de la grille EBCDIC qui est codée sur 8 bits, sont intraduisibles en
ASCII qui est codé sur 7 bits ! (256 possibilités en EBCDI, contre 128 en ASCII !).

Mon anglais me l'interdit, mais je suis sûr que les anglophobes (non, ce n'est pas une faute !),
que vous êtes sauront trouver des exemples de non correspondance entre Français et Anglais
(à part le mot : Mouton !).

Résultat, si l'on veut être sûr de pouvoir acheminer toutes les informations de manière
transparente, il faudra dénicher une syntaxe de transfert capable d'acheminer à peu près
n'importe quel type de données !! Et là ... OSI est arrivé !

ASN 1 (Abstract Syntax Notation Number One), vous connaissez ? C'est un langage de type
LTV (Longueur, Type, Valeur : à vos souhaits !) qui permet de décrire à peu près n'importe
quels types de données, et donc se présente comme leader pour le transport d'informations
hétéroclites !

Défini par la norme ISO 8824, il permet de décrire une variable (ou une donnée) par son type
(booléen, entier, réel, binaire, octet long, séquence, chaîne de caractère, etc...), sa valeur (a,
1, 125, bobo, tartuffe, NON, OUI, AND, etc ..) et sa longueur (1 bit, un octet, un mot, etc ..).

Plus fort ! L'ASN 1 est également utilisé comme langage de description de programmation. Les
requêtes SNMP pour l'adressage des objets dans les MIBs (attention, ici je m'adresse aux
experts, désolés pour les autres !), sont aussi décrits en ASN 1.

Remarques
En résumé, la couche Présentation autorise entre-autres :

• La négociation de syntaxes de transfert

• La conversion de syntaxes locales en syntaxes de transfert
• L'utilisation d'une syntaxe de transfert normalisée (ASN 1)
• La cryptage des informations à des fins sécuritaires.

Je n'ai dans ce chapitre, pas franchement parlé des méthodes de cryptages, pour au moins
deux raisons :

• Je dispose d'assez peu d'informations sur le sujet.

• La presse se fait suffisamment l'écho du problème actuellement (je te le code sur
combien ton message ? Deux ou 64 bits ? Qu'est-ce qu'il va dire le gouvernement ? Tu
crois qu'il arrivera à décoder mes messages, pour que je sois autorisé à coder sur 32
bits ?)

La couche Application
 47

Rôle
Rendre des services génériques aux applications

Ne vous laissez pas abuser par son nom. La couche application n'héberge pas du tout
l'application. Elle est là pour rendre des services aux applications placées au-dessus d'elles. En
effet, nombre d'applications ont besoin d'échanger des fichiers, d'être accessibles à distance
par des terminaux en mode caractères, de se baser sur des carnets d'adresses pour identifier
les utilisateurs, d'échanger des messages, etc...

Le développeur d'application a alors deux choix possibles :

• Il écrit du code au sein de son application qui permet de faire des transferts de fichier,
ou de l'émulation de terminal distant, ou de gérer un annuaire centralisé ou partagé,
ou encore de gérer une messagerie. C'est long, c'est cher et ce n'est pas portable
(difficilement modifiable pour s'adapter à une autre architecture), sans compter que
c'est spécifique donc pas ouvert, donc pas OSI !
• Il utilise des programmes standards de transferts de fichiers, d'émulations virtuelles
de terminaux, d'annuaires, ou encore de messageries. Il accède à ses programmes par
une interface normalisée (un Gosub, pour les accros du Basic !), plus communément
appelée API (Application Program Interface).

La couche application offre justement différents services (messagerie, transfert de fichier,

émulation de terminal, annuaire, supervision, ...). Ces services sont normalisés et sont
accessibles par des interfaces normalisées dénommées AE (Application Entity), équivalent des
API.

L'unité de données du protocole est appelée l'APDU (Application Protocol Data Unit). Cette
APDU est bien sûr en principe encapsulée dans la PPDU du niveau 6.

Analogie avec l'environnement TCP-IP

 48

La plupart d'entre-vous (par la force des choses !) appréhendent mieux l'environnement TCP-
IP que l'environnement OSI. A l'inverse de la couche Présentation qui n'a pas d'équivalant en
TCP-IP, on peut trouver dans l'architecture TCP-IP un bon équivalent de couche 7. Vous avez
tous entendu parler de FTP, Telnet ou encore SNMP ? Le premier est un protocole de transfert
de fichiers, le second un protocole d'émulation de terminal virtuel en mode caractère et le
dernier un protocole de supervision. Ces protocoles rendent des services aux applications IP
qui les utilisent (typiquement votre Netscape ou Internet Explorer !).

Ces protocoles issus de l'environnement IP, je vous le rappelle, ne sont pas normalisés ISO,
mais on trouve les équivalents dans l'environnement OSI !

Exemples de services rendus et normes associées

1 - LE TRANSFERT DE FICHIER AVEC RTSE : ReliableTransfert Service Element

• RTSE (ISO 9066) est un protocole de transfert de fichiers fiable (encore plus fiable que
FTP). Beaucoup plus connu sous le nom d'X400 en regard de son nom dans la
normalisation UIT-T.
• FTAM (File Transfer Access and Management) est une application de transfert de
fichier fiable référencée sous la norme ISO 8571.

Ces deux protocoles et application rendent des services similaires à FTP bien que beaucoup
plus évolués. On ne trouve pas dans l'environnement OSI d'équivalent du TFTP (Trivial File
Transfer Protocol) d'IP, qui fonctionne en mode non connecté (vous savez ce que ça veut dire
maintenant !). En effet l'environnement OSI fonctionne généralement en mode connecté avec
un niveau de qualité de service assez élevé, ce qui n'est pas le cas de TFTP !

2 - LA SUPERVISION D'ELEMENTS DE RESEAUX ET D'APPLICATION AVEC CMIP-CMISE :

• CMIP (Common Management Information Protocol) est un protocole de supervision

de réseau au même titre que SNMP d'IP.
• CMISE (Common Management Information Service) défini le service requis pour la
supervision (rappelez-vous ! OSI c'est des normes de services et des normes de
protocoles rendant ses services !).
• CMIP est décrit dans la norme ISO 9596.

3 - UN ANNUAIRE AVEC DS (Directory Service) :

DS (Directory Service), référencée par la norme ISO 9594-1/8 est plus connu sous le nom
d'X500, qui est en fait le nom de la norme UIT-T.
 49

Comme vous le savez sans doute, ce protocole permet de synchronisez des annuaires qui
permettent de localiser à peu près n'importe quel type de ressource (personnes physiques,
serveurs d'impressions, serveurs de fichiers, passerelles, applications, etc ...). Ces annuaires
sont très utiles pour permettre aux applications d'adresser les ressources nécessaires.

Association de processus

L'association de processus
Nous avons vu précédemment qu'une application voulant utiliser des services de couche 7,
doit s'interfacer avec un AE (Application élément), équivalent à une API. Lorsque cette
application atteint l'élément de couche 7 désiré (par exemple FTAM), elle est généralement
mise en relation avec un élément équivalent à l'autre bout de la chaîne de transmission. Il est
alors nécessaire d'opérer une synchronisation des processus, et de gérer la mise en relation
des services ne serait-ce que pour pouvoir différencier des connexions FTAM (ou autres)
distinctes et simultanées entre mêmes applications !

Cette fonction est assurée par un module dénommé ACSE (Association Control Service
Element) normalisé ISO 8649 pour le service et 8650 pour le protocole ou X217/227 à l'IUT-T.
Il permet d'offrir les fonctions de base nécessaires pour mettre en relation deux processus et
pour contrôler leur association.

Remarques
En résumé, la couche Application est une couche qui offre aux applications des sous-
programmes et protocoles standards. Les utiliser, plutôt que d'intégrer les fonctions dans un
développement spécifique, offre des avantages en terme de portabilité des processus,
d'homogénéité d'architecture, de gains en développement.

Même si la chose paraît idyllique, ne nous leurrons pas. Utiliser des protocoles OSI s'avère
souvent assez lourd et complexe. C'est pourquoi, bien souvent si l'on a besoin d'une fonction
de transfert de fichier (par exemple) légère on ne s'attachera pas les services OSI comme
FTAM ou CFT (Cross File Tranfer). On préférera un petit protocole comme FTP ou un
développement spécifique !
 50

OPTIMISATION DES PROTOCOLES

LE SOMMAIRE
 51

CHAPITRE 1 : UN PEU D'HISTOIRE

Quelques élucubrations totalement imparfaites et partiellement inexactes sur la provenance

d'IP et son environnement

A lire pour le Fun, la culture de boudoir, mais à répéter uniquement aux incompétents en la
matière !!

CHAPITRE 2 : ARCHITECTURE GENERALE ET FONCTIONS

Pour commencer doucement, un petit chapitre qui rappelle l'environnement IP et les

fonctions générales du protocole. Pas de quoi, attraper mal à la tête ! Allez-y tranquille !

CHAPITRE 3 : LE FORMAT DU DATAGRAMME IP

Ca ne peut pas toujours être les vacances ! Au début on prend peur, et puis à la fin on se dit
que finalement il n'y a pas de quoi en faire un fromage ! Si vous voulez en mettre plein la vue
à votre entourage, en parlant de trucs qu'ils comprennent pas, vous devriez trouver matière
ici ! Un chapitre qui présente succintement le format du paquet IP, histoire de préciser les
fonctions qu'est capable d'offrir IP !

CHAPITRE 4 : CONCEPTS GENERAUX SUR L'ADRESSAGE IP

C'est quoi l'adressage IP ? Petit chapitre facile où l'on traite des notions de machines et
d'interfaces, d'adresse réseau et machine, de notion de Classe d'adresses ! Mais rien de bien
MIGRAINEUX ... A LIRE AVANT DE SE COUCHER UN SOIR DE GRANDE FATIGUE !

CHAPITRE 5 : DETAIL DE L'ADRESSAGE IP

Sortez votre binaire des collèges ! On commence à entrer dans le détail ! Structure binaire
d'une adresse IP, adresses particulières (réseau et broadcast), repèrage des classes IP au
niveau binaire ... Vous pensiez pas dormir toute la journée, quand même ?

CHAPITRE 6 : LE ROUTAGE

Une adresse c'est bien beau ! Mais ça sert généralement à recevoir du courrier (Heu .. Des
paquets ici !). Comment arrive-t-on à bon port ? C'est ici que Jules entre en scène ! Il veut
surfer sur www.jebulle.com mais comment faire pour sortir du réseau ... Foncez ! C'est une
histoire palpitante !

CHAPITRE 7 : PLAN D'ADRESSAGE IP

 52

Architecte réseau : métier de tous repos ? Allez donc lire ce chapitre et vous verrez si c'est vrai
! Ici il y a des pièges, des loups qui se cachent dans le bois, des faux semblants, et des vrais de
faux ... Ne vous y fiez pas ! La vérité est ailleurs ...

CHAPITRE 8 : LES SOUS-RESEAUX ET MASQUES IP

Enfin un peu de sport ! Si le chapitre 5 ne vous a pas "collé" la migraine, vous y êtes candidat
avec ce chapitre ... Il ne sera pas dit, que vous sortirez indemne de ce cours ! Dans ce chapitre
nous nous attaquons à la définition et au calcul des sous-réseaux ... Equipement de survie :
calculette binaire et boite d'aspirine !

CHAPITRE 9 : ARP QUI EST-TU ?

Tiens ! Un chapitre qui illustre bien le dialogue inter couches. Si besoin, vous pouvez réviser le
chapitre 4 du modèle OSI. Ici IP demande à MAC (deux copains d'enfance !) d'envoyer un
paquet à quelqu'un dont il ne connaît pas l'adresse !! Vous voyez d'ici la tête de MAC ?? MAC
n'est pas un rigolo, si ARP n'était pas là pour calmer le jeu, IP pourrait aller se faire voir ailleurs
!! Ca vous donne pas envie de le lire ce chapitre ??

CHAPITRE 10 : FRAGMENTATION IP

Cédons à la mode ! Voici notre petit chapitre gorre !! Comment découper un paquet IP sans
le faire hurler et sans en mettre partout ? Suivez le maître ! Ici vous comprendrez pourquoi,
depuis tout petit, IP découpe ses paquets, comment il s'y prend (ça peut servir !), et surtout
comment il fait pour tout recoller ! Vous verrez également, que découper c'est peut-être
amusant (ça dépend pour qui !) mais que ce n'est finalement pas si judicieux que ça ! Je sais
que vous mourrez d'envie de lire ce chapitre, maintenant ! Je vous préviens tout de même,
qu'il y a peu d'images (pour les amateurs de BD !), et qu'il va falloir vous prendre la tête à deux
mains !!

CHAPITRE 11 : ICMP : C'EST QUOI ?

ICMP c'est un peu la voix d'IP ! IP est très laconique, il ne dit pas ce qu'il fait (peut-être qu'il en
rame pas une d'ailleurs !), alors ICMP cause pour lui ! C'est pas toujours très intelligent, pas
forcément utile non plus ! D'ailleurs il n'y a pas grand monde qui l'écoute ! Mais il cause quand
même ! Alors on va regarder un peu ce qu'il est susceptible de nous raconter ! OK ?

CHAPITRE 12 : UN PETIT RESUME !

Bon ! On fini par ne plus y voir très clair dans ces protocoles IP, ARP, ICMP qui s'emmèle. Si on
rajoute ces fonctions de routage, de fragmentation, de gestion du TTL et tout, et tout, on fini
franchement par s'emmêler les pinceaux (ou les neurones !). Dans ce chapitre, vous trouverez
trois organigrammes et un schéma de transfert pour essayer de faire le point ! Bon COURAGE
!

CONCLUSION : C'EST LA FIN !

 53

CHAPITRE 1 : UN PEU D'HISTOIRE

Un peu d'histoire ...
C'est encore la faute des militaires ...
C'est vrai, chacun y va de sa propre petite histoire sur IP. On trouve cependant quelques
accords. Tout le monde s'accordent à dire qu'il a pour origine un cahier des charges militaire.
En effet, l'US Army possédait déjà dans les années 60 pas mal d'ordinateurs raccordés entre-
eux par des réseaux d'échanges de messages.

Certains diront qu'IP est une des conséquences de l'effet Spoutnik ! Les US se sont, un jour,
réveillés avec un satellite Russe qui faisait Bip-Bip au dessus de leurs têtes. Celui-ci pouvait les
atteindre sans qu'ils puissent réagir (pour peu qu'il ait été armé !), et il faisait plusieurs fois le
tour de la terre en moins de temps qu'il ne faut pour le dire !

Terrorisés (craintifs ses riquains !) ils se sont rendus compte que, depuis le ciel, des missiles
correctement placés pouvaient isoler leurs centres de commandements en cassant leurs
réseaux de raccordement. Ceux-ci étaient en effet peu fiables, pas de routage de secours,
configuration manuelle, enfin bref, la préhistoire quoi !!

Ils ont donc demandé l'étude d'un nouveau réseau à commutation de paquets qui serait
capable de résister à une amputation partielle de ses infrastructures.

L' ARPA (Advanced Research Project Agency) a été chargé d'établir un cahier des charges d'un
protocole d'interconnexion des réseaux de défense américains avec reconfigurations
automatiques en cas de ruptures. C'est la définition du mode de transfert en paquets et
bientôt la naissance de l'IP/DoD (Department Of Defense).

En 1969, les premiers tests d'IP se déroulent sur un réseau de 4 noeuds interconnectés. C'est,
je pense, la première fois qu'IP se proméne si je puis dire ! Très rapidement l'armée étend son
réseau de défense sur IP et on assiste à la création d'ARPANET (ARPA Network).

Oui ... Mais si les Universités s'en mêlent ...

L'armée, pour ses besoins de recherche (d'armes toujours plus high-tech !), utilise de
nombreux scientifiques généralement basés en Universités (sauf pour la bombe A où ils les
avait mis dans un camp !!), et a donc petit à petit proposé le raccordement de certaines
universités au réseau ARPANET. Petit à petit le réseau a grossi. Et l'armée a donc isolé la partie
militaire du réseau qui s'est alors appelé : MilNet (Military Network).

Autre fait concourant à la popularisation d'IP fût la libération du code UNIX développé par ATT
(inutile de les présenter je pense !) à l'université de Berkeley (Unix BSD). IP a alors été intégré
au noyau UNIX, ce qui a largement contribué à son expansion, sachant qu'UNIX était l'OS start
de l'époque (tout ça c'était avant l'arrivée de notre Bilou International, que dis-je ... galactique
!).
 54

Et, il y a eu les LAN aussi ...

Sont apparues dans les années 70 et 80 des nouvelles technologies de réseaux sur support
dits "fiables". Ces réseaux avaient une couverture limitée à celle de l'entreprise, ils étaient
donc locaux. Ce sont des RLE (Réseaux Locaux d'Entreprises) plus connus sous l'appelation de
LAN (Local Area Network). Leurs noms vous sont sans doute familiers : Ethernet, Token Ring
ou FDDI (attention c'est un MAN : Metropolitan Area Network). Leur caractéristique principale
de support fiable, garantissait une transmission avec un minimum d'erreurs. Il n'y avait alors
plus lieu d'utiliser des protocoles complexes (connexion, gestion de flux, contrôle d'erreur,
reprise sur erreur, ...) comme X25 pour assurer le transport de l'information. Ils sont devenus
le terrain de prédilection d'IP !

Et puis, VINTCERF : le Papa d'Internet !

Puis le Papa d'Internet est arrivé : Vintcerf qui défini le protocole TCP qui va pallier aux
insuffisances d'IP. En effet, je l'ai dit, IP est un protocole très simple qui ne garanti aucune
livraison d'information, ne fait pas de contrôle ou de reprise sur erreur, n'établi pas de
connexion et encore moins de gestion de flux. Si ces caractéristiques sont garantes d'un
excellent rendement de transmission (mois de contrôles = moins d'infos de gestion = meilleur
débit utile) elles avaient du mal à s'appliquer aux réseaux longues distance de l'époque qui
étaient avouons le tout sauf performants ! Le protocole TCP a permis d'établir au-dessus d'IP
(en couche 4) une connexion entre deux machines qui permettait le contrôle et la reprise
d'erreur, la gestion de flux, et d'autres subtilités comme l'adressage de sockets ! Ce fut une
réelle avancée !

IP certes ! Mais IP et ses petits amis ...

Puis sont né un tas de protocoles annexes, véritables greffons d'IP qui sont venus enrichir les
fonctions, et ont fini par le propulser à la première place aujourd'hui. Ces protocoles sont
HTTP (pour l'HTML et le Web), NNTP (pour les News), SMTP (pour le Mail), SNMP (pour
l'administration), TELNET (pour l'émulation d'écran virtuel), ...

Certains protocoles moins connus par le grand public contribuent cependant à la notoriété
d'IP, ce sont les protocoles de routage que j'espère nous aurons un jour la chance d'étudier
ensemble. Ils se nomment RIP, EGP, IGRP, OSPF, BGP(4) et c'est en fait eux les garants de
l'acheminement de vos pages Web sur vore navigateur. Sans eux, Internet ne serait pas ce
qu'il est aujourd'hui !

Tout ça s'est bien, mais ça ne remplacera pas l'homme !

Mais le facteur le plus important dans la popularisation d'IP ne se situe pas au niveau
technique. Il est au niveau humain, et il tient à son principe d'évolution. En effet tout
l'environnement protocolaire IP est en vérité le fruit de travaux collégiaux entre des centaines
 55

de passionnés. On dit qu'Internet ne supporte aucune loi, et c'est vrai. C'est l'utilisateur qui l'a
fait évoluer en fonction de ses besoins. Chaque protocole est le résultat de travaux d'un ou
plusieurs groupes qui avaient des besoins et ont cherché des solutions. Ils ont ensuite publié
le résultat de leurs cogitations sous forme de brouillons (des DRAFTS) pour information et
participation. Lorsqu'un consensus est adopté, le DRAFT se mue en RFC (Request For
Comments = Appel à commentaire). Cette RFC fait office de norme, mais n'en est pas une.
C'est à dire que chacun peut se l'approprier, la modifier et sortir sa propre version. Il n'y a
aucune information émise sur l'évolution d'une RFC, il faut s'enquérir soit même d'une
possible évolution.

Ce principe de fonctionnement peut paraître brouillon mais il a l'avantage d'être extrêmement

dynamique ! C'est ce mode de fonctionnement qui a permis à IP de supplanter les
environnements OSI, qui s'ils sont parfaitement cernés et normalisés, n'en mettent pas moins
dix ans pour paraître !!

Oui, mais c'est qui le Chef ?

Il n'existe pas comme avec OSI, sur Internet d'organisme de réglementation des normes. Sur
Internet il n'y a pas de normes, il y a des RFC, qui comme leur nom l'indique sont des Avis que
l'on peut commenter (pour modifier !). Les seuls organismes vaguement réglementaires que
l'on peut trouver sont :

• l'IAB : Internet Architecture Board qui a pour rôle d'essayer de surveiller, planifier et
proposer les évolutions d'architecture d'Internet, en terme d'interconnexion de
noeuds de réseaux ou de protocoles de routage. Pour la petite histoire, IAB voulait au
départ dire : Internet Authority Board ! La communauté Internet a vigoureusement
protesté, arguant qu'il n'y avait pas d'autorité sur Internet ! Le sigle est resté le même
mais la définition a changée !
• l'IETF : Internet Engineering Tasks Forces, est en fait un organisme quelque peu
fantôme. Il représente l'ensemble des groupes d'utilisateurs et chercheurs qui se
forment et se cassent pour faire évoluer Internet. L'IETF est en quelque sorte
l'organisme central de publication des RFC ! Mais ce serait une coquille vide sans la
communauté Internet des passionnés qui se réunissent pour changer le monde des
transmissions IP.
• le NIC : qui a aujourd'hui énormément délégué ses responsabilités au niveau national
a en charge la cohérence du plan d'adressage dans le réseau Internet ainsi que la
cohérence du nommage des machines (le DNS pour les intimes). En France il est relayé
par l'AFNIC, et vient aussi de déléguer les noms de domaine à Oléane (filiale récente
de France Télécom).

Conclusion du chapitre
 56

Voici une petite présentation de la naissance et de l'environnement d'IP, qui en vaut bien une
autre ! A l'évidence le nombre de facteurs à prendre en compte est suffisamment important
pour justifier les différentes versions que l'on peut entendre.

Dans les prochaines pages nous entrerons dans le vif de la technique et laisserons ces
interprétations politico-économico-sociolo-historiquo aux érudits

CHAPITRE 2 : ARCHITECTURE GENERALE ET FONCTIONS

Présentation générale d'IP

Interconnexion de niveau 3

IP : Un protocole de niveau 3 à tout faire !

Internet Protocol (IP) est un protocole de niveau 3 OSI. Mais attention ! IP n'est pas référencé
(normalisé) ISO ... Si vous avez lu le cours sur le modèle OSI, vous savez de quoi je parle !

IP est capable d'interfacer avec différents types de sous-réseaux aux niveaux inférieurs (niveau
2 et 1). Sa structure "légére" et peu contraignante le prédispose pour n'importe quel type de
support. Ses fonctions de segmentation lui permettent de s'adapter à n'importe quelle taille
de trame de niveau 2 par exemple, pour le peu qu'elle puisse au minimum véhiculer son en-
tête (32 octets).

Les trames de niveau 2 peuvent véhiculer divers protocoles de niveau 3. Généralement elles
prévoient un champ qui leur permet d'indiquer quel protocole de niveau 3 elles véhiculent
dans leur champ de données. Ainsi si le sous-réseau est de type X25 (oui, je sais ! X25 est plutôt
niveau 3, mais on peut encapsuler de l'IP dans du X25 ! Faut le savoir !), le lien avec le protocole
IP se fait en positionnant le champ données utilisateur à la valeur hexadécimale : CC (dans le
cas d'un Circuit Virtuel Commuté : CVC). Lorsque le sous-réseau est de type Ethernet, la valeur
du champ type de la trame est (08 00)h.

A son tour, IP est également capable de véhiculer différents protocoles de niveaux supérieurs
(généralement du niveau 4). Les principaux protocoles sont TCP et UDP.
 57

L'empilement (stack) IP

Succintement : l'environnement protocolaire IP ...

J'ai promis de ne pas m'étendre sur l'ensemble du stack IP, pour plutôt me concentrer sur IP,
protocole de niveau 3. Je vous présente donc, très rapidement, les principaux protocoles
annexes, de l'environnement IP, avec une description très rapide de leurs rôles.

INTERNET PROTOCOL (IP)

Permet le routage d'une information à travers des sous-réseaux hétérogènes.

INTERNET CONTROL MESSAGE PROTOCOL (ICMP)

C'est un protocole administratif pour signaler les problèmes à l'émetteur d'un datagramme
(paquet). Il assure des fonctions comme le contrôle de flux, qui ne sont pas rendues par IP.

ADDRESS RESOLUTION PROTOCOL (ARP)

C'est le protocole qui permet à une station émettrice d'un datagramme de connaître l'adresse
physique correspondant à l'adresse IP. Nous aurons l'occasion d'y revenir, mais sachez que
pour qu'une station lise le contenu d'un datagramme, il faut qu'il est son adrese et qu'il soit
inclus dans une trame à l'attention de la station.

REVERSE ADDRESS RESOLUTION PROTOCOL (RARP)

 58

Permet à une station ne connaissant pas son adresse IP de la demander à un serveur.

Transmission Control Protocol (TCP)

Protocole d'équivalent couche 4 OSI, permettant d'établir une connexion à travers un réseau
IP. Assure également des fonctions de contrôle de flux et d'erreurs.

User Datagram Protocol (UDP)

Méthode simple de transport de l'information en mode non connecté sans contrôle de flux.
Nous dirons que c'est un TCP "ligth" !

Terminal Virtuel (Telnet)

Emulateur de terminal en mode caractère permettant l'accès à une application distante.

File Transfert Protocol (FTP)

Protocole et spécifications fonctionnelles d'application permettant le transfert de fichiers et

leur gestion à distante dans un mode fiable, en utilisant TCP.

Simple Mail Transfert Protocol (SMTP)

Protocole et spécifications fonctionnelles d'application permettant le routage et la gestion de

la messagerie.

Trivial File Transfert Protocol (TFTP)

Protocole et spécifications fonctionnelles d'application permettant le transfert de fichiers

dans un mode non fiable, en utilisant UDP.

BootP

Protocole et spécifications permettant à une station de télécharger sa configuration réseau

(@IP, Gateway, DNS, etc.) notamment en utilisant le protocole DHCP.

Fonctions principales d'IP ...

IP en tant que protocole de niveau 3, dit protocole de couche réseau, offre les fonctions
suivantes :

• un format de paquet normalisé permettant de véhiculé au maximum 65536 octets

• un format d'adressage normalisé et mondialement contrôlé afin de garantir une
parfait interopérabilité des différents réseaux
• des mécanismes de priorisation des paquets dans le réseau
• un mécanisme de segmentation des paquets pour lui permettre d'être véhiculé dans
des trames de niveau 2 de MTU (Maximum Transmission Unit) de tailles différentes.
 59

• un champ option permet également de fournir des fonctions moins courantes. Nous
les décrirons succinctement car elles sont très peu utilisées.

La suite de ce cours, s'attachera donc à développer les points les plus importants, listés ci-
dessus.

Conclusion du chapitre
Ce chapitre générique avait pour but de vous rappeler brièvement les fonctions et rôles d'un
protocole de niveau 3 OSI (même si IP n'est pas normalisé ISO), et de vous présenter
succinctement les grandes fonctions d'IP et de son environnement. Le chapitre suivant va
clairement entrer dans le sujet !
 60

CHAPITRE 3 : LE FORMAT DU DATAGRAMME IP

Le Datagramme IP
Commencer la description du protocole IP, par une présentation du format du paquet
(datagramme) peut sembler osé. Certains trouveront que l'approche est trop complexe, mais
il n'en est rien. En effet, pour mettre en ouvre des fonctions (priorisation, contrôle de flux,
détection d'erreurs, etc.) un protocole doit prévoir dans son format de PDU, et notamment
dans son PCI, les champs nécessaires à la mise en œuvre de ces fonctions.

Autrement dit, étudier le format d'une PDU d'un protocole, renseigne immanquablement sur
les fonctions qu'il offre. Ce chapitre présente donc le datagramme IP sans trop insister sur les
différents champs. Les chapitres suivants, traitant des plus importantes fonctions d'IP,
s'appuieront sur le format des champs, plus en détails.

Le paquet IP

Format général du paquet

Vous l'avez remarqué, on dit tout aussi bien "paquet", que "datagramme". En théorie, un
datagramme véhicule toutes les informations nécessaires à son routage (notamment les
adresses sources et destinations), alors qu’un paquet est beaucoup plus générique et pourrait
fort bien ne pas comporter ces informations. Quoiqu'il en soit, nous dirons que "paquet" et
"datagramme" c'est la même chose !

Un paquet IP moyen a une taille de 128 ou 256 octets. Avec l'arrivée des technologies ATM à
très hauts débits, on commence à vulgariser des tailles plus importantes aux alentours des
1500 octets.

Le paquet IP est formé de deux grandes parties :

• l'entête du paquet, généralement d'une taille de 20 octets, constitue le PCI du protocole. C'est
là que sont inscrites toutes les informations du protocole (adresse, segmentation, options,
etc.).
• la partie "data", ou champ de données, d'une taille maximum de : (65536 octets) - (les octets
d'entête et d'options). Elle véhicule la PDU de couche supérieure (généralement un segment
TCP ou UDP).
 61

L'analyse du champ de données ne nous apprendra rien, si ce n'est le format de la PDU TCP
ou UDP, mais ce n'est pas le sujet de ce cours. Nous allons donc focaliser sur l'entête, qui vous
le verrez est très intéressante !

L'entête IP

Format général de l'entête du paquet

L'entête IP, comme tout le paquet IP est structurée en mots de 4 octets. C'est une des raisons
qui a conduit a refusé la normalisation d'IP dans le modèle OSI, qui préconise une structure
en mots de 1 octet.

Structure en mots de 4 octets veut dire que le nombre d'octets d'un paquet IP est toujours
un multiple de 4 octets. Si on doit placer un nombre d'octets non multiple de 4 dans le paquet
(65 par exemple), on procède à un complément, encore appelé "bourrage" pour les moins
élégants, ou "padding" pour les cultivés ! Cette opération consiste à ajouter un nombre
d'octets supplémentaires formés de 0, qui vont compléter jusqu'à un multiple de 4. Pour notre
exemple, on ajouterai 3 octets pour obtenir 68 octets (68/4 = 17 mots de 4 octets).

L'entête IP standard n'utilise pas le champ "Option", elle a donc une longueur de 20 octets (5
mots de 4 octets) dans 99% des cas.

Le champ d'option peut avoir une longueur très variable. Nous le présentons succinctement,
plus loin.

Rôles des champs de l'entête

L'entête IP, comme tout le paquet IP est structurée en mots de 4 octets. C'est une des raisons
qui a conduit a refusé la normalisation d'IP dans le modèle OSI, qui préconise une structure
en mots de 1 octet.
 62

Version

Ce champ code sur 4 bits, la version du protocole. La version actuelle est la version 4 (0100).
Une version 6 est annoncée depuis bientôt 6 ans ! On commence à en voir certaines
implémentations, mais le chemin est encore long. Elle introduit un nouveau format
d'adressage permettant d'affecter une adresse IP à n'importe quoi sur terre, avec plusieurs
milliards d'adresses possibles ... Peut-être un jour en parlerons-nous ... Mais il faudra que je
me documente sur la chose ...
Internet Header Length (IHL)
Longueur de l'en-tête Internet, exprimée en mots de 4 octets. Cette longueur étant codée sur
4 bits, elle peut avoir comme valeur maximum binaire 1111 soit 15. Comme elle indique un
nombre de mots de 4 octets, on en déduit que la taille maximum de l'entête IP est de 15*4 =
60 octets.

Type Of Service (TOS)

Ce champ donne des indications aux équipements qu'il traverse sur son niveau de priorité et
sa classe de service. Défini sur 8 eb (1 octet), il est divisé en 5 parties :

• Les bits 0 à 2 indiquent la "précédence". Autrement dit la priorité d'acheminement par rapport
aux autres paquets. Cette partie du champ permet de définir 8 niveaux de prioritté
d'acheminement.
• Le bit 3 indique si le paquet peut supporter une attente de traitement normale ou faible.
• Le bit 4 indique si le paquet doit être acheminé en priorité sur des liens à hauts débits ou non
• Le bit 5 indique si le paquet doit être acheminé sur des liens très fiables (faible taux
d'indisponibilité et d'erreurs) ou normaux
• Les bits 6 et 7 sont réservés et donc inutilisés.

Quoiqu'il en soit, ce champ est rarement utilisé. Avec l'arrivée de nouvelles technologies
comme le MPLS (Multi Protocol Label Switching) on commence à utiliser le champ TOS bits 0
à 2 pour définir des classes de services qui sont exploitées par MPLS. Certaines applications
utilisaient déjà ce champ TOS pour définir des priorités d'acheminement de leurs paquets dans
le réseau, mais cela restait rare !

Tableau des valeurs du champ pour un paquet IP/DoD

• 111: contrôle de réseau
Bits 0-2 • 110: contrôle de réseau Arpanet
• 101: Critic/ECP
• 100: flash override
• 011: flash
• 010: immédiat
• 001: priorité
• 000: routine
Bit 3 • 0: attente normale
• 1: attente faible
Bit 4 • 0: débit normal
• 1: débit élevé
Bit 5 • 0: fiabilité normale
 63

• 1: fiabilité élevée
Bits 6-7 • 00: réservés

Total Length

Longueur totale du datagramme, exprimée en octets, en-tête et données comprises. Ce

champ étant codé sur 2 octets, la longueur maximale d'un paquet IP est donc de 65 536 octets
(0 à 65535).

Identification, Flags et Fragment Offset

Ces trois champs servent à gérer le mécanisme de fragmentation (ou segmentation si vous
préférez) du paquet IP. En effet, il est possible qu'un paquet IP n'entre pas entièrement dans
une trame de niveau 2 parce que sa taille est trop importante. Il sera nécessaire de fragmenter
le paquet pour le véhiculer dans plusieurs trames.

Cependant en raison de la nature non connecté du protocole, la fragmentation est assez

complexe à gérer. Nous étudierons cet aspect plus complétement dans un chapitre suivant.

Pour le moment retenez qu'un mot complet de 4 octets est réservé à la gestion de la
fragmentation.

Time To Live

Toujours en raison du fait que le protocole IP fonctionne en mode non connecté, que de plus
im est capable d'implémenter des techniques de routage dynamique susceptible de lui
permettre de changer de route pour acheminer ses paquets, il est possible qu'un paquet se
perde dans le réseau. Pour éviter qu'il tourne indéfiniment, on lui affecte une durée de vie.
Durée de vie du datagramme. Cette valeur est décrémentée toutes les secondes ou à chaque
passage dans une passerelle. Si cette valeur est à 0, le datagramme est mis au rebut.

Protocol

Ce champ codé sur un octet, identifie le protocole de niveau supérieur transporté dans le
champ de données du paquet IP. Il permet au destinataire, en analysant ce champ, de savoir
à quel protocole de niveau supérieur (niveau 4 en général : TCP ou UDP) il doit transmettre le
contenu du datagramme.

Tableau des valeurs du champ protocole

Hexadécimal Décimal Protocole Nom
01 1 ICMP Internet Control Message Protocol
06 6 TCP Transmission Control Protocol
08 8 EGP Exterior Gateway Protocol
09 9 IGP Interior Gateway Protocol
11 17 UDP User Datagram Protocol
1D 29 ISO-TP4 Transport Iso Classe 4

Checksum
 64

Le checksum est le champ de contrôle d'erreur. Il est calculé uniquement sur l'en-tête. Le
principe consiste à faire la somme des valeurs des octets de l'entête et à inscrire les résultats
dans l'octet de checksum. Le récepteur effectue la même opération, si la valeur trouvée est
identique, il n'y a pas d'erreur. Dans le cas contraire, le paquet est rejeté.

ATTENTION : IP possède un mécanisme de détection d'erreurs, mais pas de correction

d'erreurs. Autrement dit, il jette le paquet, mais n'informe personne et ne cherche pas à
générer une répétition du paquet (réémission par l'émetteur). Les couches supérieures
devront gérer elles-mêmes cette perte de paquet est s'occuper des demandes de réémissions
éventuelles.

Comme certains champs de l'entête peuvent varier dans le temps, le checksum est recalculé
par chaque équipement traversé par le paquet.

Adresses destination et source

Les champs d'adresses sont chacun codés sur 4 octets. Il existe donc, en théorie, 2 puissance
32 adresses possibles (4 294 967 296 adresses). Dans le chapitre consacré à l'adressage, nous
étudierons précisément ce format.

Le champ adresse Source indique l'adresse IP de la machine qui émet les données, le champ
adresse Destination indique l'adresse IP de la machine à qui sont envoyées les données.

Options

Je vous l'ai déjà indiqué, ce champ est assez peu utilisé. Il permet de mettre en oeuvre des
mécanismes évolués comme le routage par la source (l'émetteur indique par où doit passer le
paquet) ou l'enregistrement de routes (le paquet enregistre par où il est passé pour arriver à
destination).

La longueur totale de la partie options doit être un multiple de quatre octets. Il y a donc une
possibilité de "padding" (bourrage) à la fin de la section options.

Tableau des principales options

Tableau des principales options

Hexa. Déc. Type Fonction
00 0 Fin d'option Termine la partie options
01 1 Pas d'opération Permet de commencer sur un multiple de quatre
octets (bourrage ou padding).
07 7 Enregistrement de route Chaque relais doit insérer son adresse IP associée
au réseau
44 68 Enregistrement d'instant Possibilité d'insérer l'instant de réception,
l'adresse IP
82 130 Sécurité Spécifique DOD
83 131 Routage approximatif Si adresse source reconnue, remplacement par
adresse réseau
88 136 Identificateur de stream Spécifique STATNET
89 137 Routage impératif Routage à travers les passerelles spécifiées
 65

Conclusion du chapitre
Par la connaissance du format de l'entête IP, et du paquet en général, vous avez maintenant
une idée plus précise des fonctions offertes par le protocole. Dans les chapitres suivants, nous
allons détailler certaines fonctions.
 66

CHAPITRE 4 : CONCEPTS GENERAUX SUR L'ADRESSAGE IP

L'adressage IP : concepts généraux ...
IP est un protocole de niveau 3. A ce titre, une de ses fonctions premières est de permettre le
routage dans un réseau. Qui dit réseau, dit ensemble de machines interconnectées entre-
elles. Pour identifier une communication au sein de ce réseau, il faut être en mesure
d'identifier les entités en communication. Cette identification est réalisée par l'adresse de
chaque machine.

Le protocole IP propose donc un format d'adresse standardisé qui permet d'identifier de

manière unique une machine au sein d'un réseau. Un datagramme IP véhiculera
simultanément deux adresses :

• l'adresse source qui est l'adresse IP de la machine qui a formaté et qui émet le paquet IP
• l'adresse destination, qui est inscrite par la machine émettrice, et qui correspond à l'adresse
de la machine pour qui est destiné le paquet IP.

Chacune de ces adresses, nous l'avons vu précédemment, est formatée sur 4 octets.

Adresse machine ou adresse d'interface ?

Une petite subtilité doit être précisée. En fait, IP n'affecte pas une adresse à une machine,
mais à l'interface d'une machine. Ainsi une machine qui disposerait de plusieurs interfaces
raccordées à un réseau (un routeur par exemple), serait dotée de plusieurs adresses IP, une
par interface.

Ce n'est pas le cas d'autres protocoles comme DRP de Decnet Phase IV, par exemple, qui
affecte une seule adresse à une machine quel que soit son nombre d'interfaces réseaux.

Retenons donc qu'IP fixe une adresse à une interface réseau et pas à une machine.
 67

Le réseau et la machine dans le réseau

Rappelons qu'IP a été conçu pour interconnecter des réseaux. Il est capable de fonctionner
sur des sous-réseaux hétérogénes. Dès le départ, et ses capacités d'adressage le prouvent, il
a été pensé pour de très grands réseaux. Si seule l'adresse machine avait été définie comme
élément remarquable dans l'adressage, il aurait fallu que les équipements d'interconnexions
identifient précisément chaque machine, ce qui aurait rapidement fait "exploser" leurs
mémoires (plus de 4 milliards d'adresses).

En conséquence, et à l'instar de beaucoup de protocoles de niveau 3, une hiérarchie est

définie dans le format d'adresse IP. Une adresse IP est scindée en deux parties :

• l'adresse réseau : elle identifie un groupe de machine, généralement regroupées sur un même
sous réseau physique (Ethernet, Token Ring, X25, etc.)
• l'adresse machine : elle identifie la machine dans le sous-réseau considéré.

Retenons donc deux points :

• une adresse IP possède une partie réseau et une partie machine

• une adresse réseau identifie généralement un sous-réseau physique

Représentation normalisée de l'adresse IP

J'espère ne rien vous apprendre, en vous disant que l'adresse IP est comprise sous forme
binaire par les machines ! Par contre, nous, les hommes, avons une convention de
représentation de l'adresse IP. En effet, la décliner sous forme binaire reléve plus de la torture
que de l'information ! Il y a tout de même 4 octets, soit donc 32 bits !

Nous représentons donc l'adresse IP sous forme décimale. On inscrit chacun des 4 octets sous
sa forme décimale et on les sépare par un point. Par exemple :

10.0.1.254 donne en binaire : 00001010.00000000.00000001.11111110

Vous admettrez que notre représentation est plus sympa que le binaire ?
 68

Retenons donc, qu'une adresse IP s'annonce sous la forme X.X.X.X avec X compris entre 0 et
255 (255 étant la valeur décimale maximale pour un octet ... Faites le calcul !!).

Les classes d'adresses IP

Nous avons vu précédemment que :

• une adresse IP possède une partie réseau et une partie machine

• une adresse réseau identifie généralement un sous-réseau physique

Il n'est pas surprenant d'imaginer qu'il existe des sous-réseaux physiques de tailles différentes
supportant plus ou moins de machines. Si l'adressage IP avait fixé "dans le marbre" la
répartition des octets réseaux et machines dans son format d'adresse, nous aurions pu être
confronté au problème de ne pas avoir assez d'adresses machines pour un sous-réseau
physique donné. Dans un autre cas, on aurait également pu "gaspiller" de l'adresse en utilisant
moins d'adresses machines, pour un sous-réseau de peu de machines, que ne l'autorise
l'adresse réseau IP. Est-ce clair ?

Supposons que le répartition dans l'adresse impose les deux premiers octets comme réseau,
et les deux octets suivants comme machine. Soit R.R.M.M (R = octet réseau ; M = octet
machine). Dans ce format il est donc possible d'adresser 65536 réseaux comportant chacun
65536 machines. On voit immédiatement deux problèmes :

• peu de sous-réseaux supportent 65536 machines ! Je dirai même, très, très peu ! Pour chaque
adresse de réseau on va donc "gaspiller" des adresses machines qui seront inutilisées.
• si on applique ce format d'adresse au réseau internet, qui interconnecte des millions
d'ordinateurs faisant chacun partie d'un sous-réseau physique distinct, nous allons être un peu
"juste" avec nos 65536 adresses !

On peut donc résoudre ce problème en changeant la répartition réseau-machine dans

l'adresse. Si on utilise un format R.R.R.M, on disposera sans doute d'assez d'octets réseaux
(environ 16 millions d'adresses réseaux) mais par réseau on ne pourra mettre en théorie (plus
tard, vous verrez pourquoi je dis, en théorie !) qu'au maximum 255 machines par réseau.

La dernière répartition serait éventuellement R.M.M.M (255 sous-réseaux physiques avec 16

millions de machines par réseau !). Vous voyez le problème ? Je n'insiste pas ?

Diantre ! Mais dans ces 3 choix, quelle est la bonne solution ? Aucune particuliérement ...
Toutes !!

En fait, IP propose les 3 formats d'adresses appelés "Classes d'adresses" :

• la classe A est du format R.M.M.M

• la classe B est du format R.R.M.M
• la classe C est du format R.R.R.M

Vous avez ainsi le choix, en fonction de vos besoins en adresses réseaux et adresses machines
! Beaucoup d'entre-vous doivent avoir les yeux ronds en imaginant des réseaux de 16 millions
 69

de machines (classe A). Calmez-vous ... Plus tard nous parlerons de découpage d'une adresse
réseau en sous-réseaux (subnets), et vous verrez que ce sera logique !

Il existe encore deux autres classes d'adresses :

• la classe D est utilisée pour des formats d'adresses spécifiques appelées "adresses de diffusion
ou multicasts"
• la classe E est reservée pour des expérimentations

Conclusion du chapitre
Dans ce chapitre je vous ai présenté les principes généraux de base de l'adressage IP. Vous
savez maintenant :

• qu'une adresse IP s'applique à une interface machine

• qu'une adresse est définie sur 4 octets et s'énonce au format décimal pointé
• qu'une adresse présente une partie réseau et une partie machine
• qu'il existe trois classes principales d'adresses IP

Dans le chapitre suivant, nous allons rentrer un peu plus dans le détai ! Sortez vos calculettes
scientifique et enclenchez le mode binaire ... Si vous n'avez pas de calculette, sortez la boite
d'aspirine !

CHAPITRE 5 : DETAIL DE L'ADRESSAGE IP

 70

L'adressage IP
Un peu plus loin sur les classes d'adresses
Dans le chapitre précédent nous avons abordé la notion de "classes d'adresses". IP propose
trois classes principales, chacun d'entre-elles proposant une répartition différente des octets
réseaux et machines :

• Classe A : R.M.M.M
• Classe B : R.R.M.M
• Classe C : R.R.R.M

Bien ! Admettons ! Alors l'adresse 10.234.12.25, adresse de classe A, B ou C ? Bonne question

à laquelle vous ne savez pas répondre si vous n'avez pas connaissance de ce qui suit !

Pour différencier les classes d'adresses, IP se référe à la valeur du premier octet de l'adresse :

• si la valeur de l'octet est comprise entre 1 et 126, l'adresse est de classe A. Le premier octet
indique le réseau, les trois suivants indiquent la machine dans le réseau.
• si la valeur de l'octet est comprise entre 128 et 191, l'adresse est de classe B. Les deux
premiers octets indiquent le réseau, les deux suivants indiquent la machine dans le réseau.
• si la valeur de l'octet est comprise entre 192 et 223, l'adresse est de classe C. Les trois
premiers octets indiquent le réseau, le dernier octet indique la machine dans le réseau.

Les curieux doivent se demander pourquoi des valeurs limites comme 126, 191 ou 223 ?
N'oublions pas qu'IP se décline, pour nous, en décimal mais que les machines le traitent en
binaire ! En fait une machine va repérer la classe d'une adresse, non pas sur la valeur du
premier octet mais sur la valeur des premiers bits de l'octet :

• si l'octet est de la forme binaire 0xxxxxxx (avec x égal à 1 ou 0 bien sûr !), l'adresse est de classe
A. La valeur décimale de cet octet peut donc être comprise entre 0 (00000000) et 126
(01111110). Dans le paragraphe "Adresses particulières" nous verrons pourquoi les valeurs
décimales 0 et 127 sont exclues de la classe A.
• si l'octet est de la forme binaire 10xxxxxx, l'adresse est de classe B. La valeur décimale de cet
octet peut donc être comprise entre 128 (10000000) et 191 (10111111).
• si l'octet est de la forme binaire 110xxxxx, l'adresse est de classe C. La valeur décimale de cet
octet peut donc être comprise entre 192 (11000000) et 223 (11011111).

Facile non ? La machine repère dès les trois premiers bits de l'adresse sa classe ! Entre-nous,
vous préférez la version décimale ou binaire ?
 71

Les adresses particulières

Les plus attentifs auront remarqué que l'adresse 0.0.0.0, de classe A en théorie, n'était pas
proposée. Il existe des formats spécifiques d'adresses qui ne peuvent pas être affectés à une
machine (INTERFACE d'une machine, mais vous le savez maintenant ... Je peux vulgariser un
peu ?). Ces deux formats sont :

• l'adresse réseau : adresse spécifique qui identifie un réseau (incluant du même coup toutes
les machines du réseau). Cette adresse est utilisée par les équipements d'interconnexion de
réseaux que l'on appelle des routeurs. Dans le paragraphe suivant nous étudierons le routage
de IP de base, vous comprendrez ce qu'est un routeur. Ces routeurs utilisent des tables de
routage pour router les paquets. Ces tables indiquent des directions pour atteindre des
réseaux. Il est donc nécessaire de pouvoir définir un format d'adresse qui identifie un réseau.
• l'adresse de "broadcast" : dite adresse de diffusion. Cette adresse permet d'indiquer qu'un
paquet est émis à l'attention de toutes les machines du réseau IP d'un réseau IP.Elle se décline
en deux formats les adresses de "diffusion limitée" et de "diffusion dirigée"

L'adresse réseau

Le format de cette adresse est simple : on place à 0 la partie machine de l'adresse :

• l'adresse réseau d'une adresse de classe A est donc de la forme : R.0.0.0 (avec 0<R<127<
STRONG>)
• l'adresse réseau d'une adresse de classe B est donc de la forme : R.R.0.0 (avec 127<R1<192<
STRONG>)
• l'adresse réseau d'une adresse de classe C est donc de la forme : R.R.R.0 (avec 191<R1<224<
STRONG>)

Lorsqu'on indique l'adresse 10.0.0.0, on désigne l'ensemble des machines du réseau 10.
Lorsqu'on indique l'adresse 162.10.0.0, on désigne l'ensemble des machines du réseau
162.10. Enfin lorsqu'on indique l'adresse 192.145.182.0, on désigne l'ensemble des
machines du réseau 192.145.182.

L'adresse 0.0.0.0 pourrait donc indiquer toutes les machines du réseau 0. Mais le réseau 0
n'existe pas ! On pourrait donc dire qu'elle désigne l'ensemble des machines de tous les
réseaux (le réseau IP galactique, quoi !). Pas du tout ! Elle représente deux choses selon la
machine qui l'interprète :

• Pour un routeur, elle signifie le réseau par défaut ou plus précisément la route par défaut.
Elle indique la route à emprunter pour tous les réseaux qui ne sont pas explicitement décrit
dans la table de routage. Nous reviendrons sur cet aspect dans le chapitre suivant.
• Pour une machine IP en général, elle est utilisée pour indiquer "réseau courant", autrement
dit, le réseau sur lequel je suis mais dont je ne connais rien ! En fait certaines machines ne
conservent pas leur adresse IP à la mise hors tension. Donc au "boot" elle vont chercher à
recevoir une adresse IP en la demandant à des serveurs, c'est la procédure RARP. Ce format
d'adresse est utilisée dans ce cas (et dans quelques autres).

Pour le cas du routeur central ci-contre, il a dans sa table de routage :

 72

• pour atteindre 167.10.0.0 passer par le routeur X1 sur mon interface 2

• pour atteindre 12.0.0.0, passer par le routeur X2 sur mon interface 3
• pour atteindre 0.0.0.0, passer par le routeur X3 sur mon interface 1

Si ce routeur reçoit un paquet à destination de 13.0.0.0 il l'enverra à X3, car il n'a pas de
route explicite pour le réseau 13.0.0.0, il route donc par défaut sur X3 !

ATTENTION :

L'adresse réseau ne peut jamais être affectée à une machine IP comme adresse d'interface.
Elle est générée en source ou destination dans certains paquets par le stack IP dans certaines
configuration.

L'adresse de diffusion ("broadcast")

L'adresse de diffusion dirigée

Elle n'est utilisée qu'en adresse de destination. Elle indique que le paquet est à destination
de toutes les machines du réseau identifié par la partie réseau de l'adresse. Elle est
transférée par les routeurs jusqu'au réseau de destination.

Le format est très simple : on place à 1 toute la partie machine.

ATTENTION : on place à 1 chaque bit de la partie machine, un octet complet prend donc la
valeur 255 (11111111) :
 73

• l'adresse "broadcast" d'une adresse de classe A est donc de la forme : R.255.255.255 (avec
0<R<127)< STRONG>
• l'adresse "broadcast" d'une adresse de classe B est donc de la forme : R.R.255.255 (avec
127<R1<192)< STRONG>
• l'adresse "broadcast" d'une adresse de classe C est donc de la forme : R.R.R.255 (avec
191<R1<224)< STRONG>

L'adresse de diffusion limitée

Elle n'est utilisée qu'en adresse de destination. Elle indique que le paquet est à destination
de toutes les machines du réseau sur lequel il est émis. Ces paquets ne sont pas transférés
par les routeurs ils restent dans leurs réseaux physiques d'émission.

Le format est encore plus simple : on place tout à 1.

ATTENTION : on place à 1 chaque bit de la partie réseau et machine, un octet complet prend
donc la valeur 255 (11111111). L'adresse de diffusion limitée est donc du format décimal :
255.255.255.255

L'adresse de Loopback

L'adresse de bouclage local ("loopback")

Cette adresse spécifique est l'adresse : 127.X.X.X avec X.X.X égal à n'importe quoi compris
entre 0.0.0 et 255.255.255. Dans 99,99% des cas on utilise l'adresse 127.0.0.1, si on ne le fait
pas c'est uniquement par snobisme, pour ne pas faire comme les autres ! Elle indique, quelle
que soit la valeur X.X.X, que le paquet émis par cette machine, lui est émis ! Autrement dit,
 74

elle permet à une machine de s'envoyer elle-même un paquet ! C'est de la communication

intra-machine. Vous trouvez ça ridicule ? Vous avez tort ! Explication ...

Imaginez une machine qui supporte plusieurs programmes distincts étant forcément localisés
sur une même machine, du moins prévu comme tels lors de leur développement. Pour faire
communiquer ces deux programmes, vous pouvez développer une interface spécifique
d'accès entre les deux à la condition que vous développiez les deux programmes ! Si vous
n'êtes pas le créateur de l'un de ses programmes vous risquez de rencontrer des difficultés.
Maintenant si au lieu de tenter de joindre ce programme en interne, vous utilisez un transfert
par l'adresse IP de la machine, vous serez considéré par ce programme comme un utilisateur
externe à la machine, et il vous répondra !

Mais votre développement va être installé sur différentes machines donc vous ne pouvez pas
prédire l'adresse IP de la machine qui l'hébergera. En prévoyant d'utiliser l'adresse de
"loopback", vous êtes certain d'appeler la machine qui supporte le programme appelant !

Un exemple simple :

Vous avez réalisé de superbes pages HTML, sur votre PC. Pour les tester il vous suffit de lancer
votre navigateur et de sélectionner la page d'entrée par la fonction "Fichier, Ouvrir". Vous
pouvez généralement aussi double-cliquer la page depuis votre Explorateur de fichier. Cette
technique fonctionne bien si vos pages sont "statiques", autrement dit avec une extension
".htm" ou ".html".

Si vous êtes un peu plus érudit dans le domaine, vous vous êtes peut-être lancé dans la
conception de sites dynamiques en ASP ou PHP. Cette fois, si vous utilisez la méthode
précédente, vous allez vous faire insulter par votre navigateur ... Pourquoi ? Parce que les
scripts ASP ou PHP sont des scripts serveurs à l'inverse de l'HTML ou du JavaScript qui sont
des langages clients. Autrement dit, l'HTML est interprété par votre navigateur alors que l'ASP
est interprété par le serveur, qui va généré une page HTML en fonction des instructions du
script. Pour interpréter l'ASP ou le PHP il vous faut donc un serveur Web. Supposons que vous
ayez un serveur Web installé sur votre PC (type PWS par exemple) ou que vous ayez placé vos
pages sur un serveur qui vous est physiquement accessible.

Supposons que pour une raison quelconque vous ne connaissiez pas l'adresse IP de votre
machine, ni son nom de serveur Web. Vous voulez cependant tester vos pages, depuis le
navigateur installé sur ce serveur ! Comment faire ?

Il vous suffit d'entrer dans la barre d'adresse : http://127.0.0.1/monsite/ (avec monsite = nom
du répertoire dans lequel vous avez installé vos pages).

Avec cette commande, vous indiquez au navigateur d'aller chercher un serveur HTTP à
l'adresse IP 127.0.0.1. Quand le stack IP reçoit cette adresse destination, il procéde à un
bouclage au niveau du stack et remonte le paquet vers ses couches supérieures.

L'adresse 127.X.X.X ne peut donc, bien sûr, être utilisée comme adresse de station.
 75

La capacité d'adressage
Fort des différents enseignements présentés ci-dessus, à votre avis : Combien de machines
peut-on installer sur un réseau IP de Classe C ?

En théorie on pourrait dire : 255 puisqu'en Classe C, un octet est réservé à la partie machine.
Mais en vérité 254, puisque l'adresse R.R.R.0 est réservée pour désigner le réseau et l'adresse
R.R.R.255 est réservée pour le "broadcast".

Plus généralement,

si dans une adresse IP, N bits sont réservés à la partie machine, on pourra installer au maximum (2puissanceN) -
2 machines.

Par exemple, si 4 bits sont réservés on installera au maximum 2p4-2 = 16-2 = 14 machines.

Retenez cette formule ! Elle vous permet de déterminer précisément la Classe d'adresse IP
dont vous avez besoin en fonction du nombre de machines à installer ! Pour être tout à fait
juste, ce n'est pas le choix de la Classe qui est le plus complexe ... Cela se "corse" vraiment
lorsque vous allez divisé votre adresse réseau en sous-réseaux !

Conclusion du chapitre
Pas trop mal à la tête ? Le binaire, c'est une seconde nature pour vous ?

Dans ce chapitre je vous ai présenté l'adressage IP de base. Vous connaissez tout des 3 classes
principales d'adresses et des adresses spécifiques IP. Mais il vous manque encore deux notions
impératives dans l'adressage IP :

• Comment on route IP ?
• Comment définir un plan d'adressage satisfaisant ?

C'est l'objectif des chapitres 6 et 7. J'aurais pu tenter de vous présenter les notions de sous-
réseaux et masque directement après ce chapitre, mais je pense que sur un plan pédagogique
se serait une erreur. En effet, pour bien comprendre le sous-réseau, il faut avoir quelques
notions de routage. Le chapitre 6 vous présente donc les éléments de base du routage IP et le
chapitre 7 vous présente les éléments de base à ne pas oublié pour définir un plan
d'adressage, il justifie également de l'utilité des sous-réseaux. Le calcul des sous-réseaux et la
notion de masque sont abordés au chapitre 8.

CHAPITRE 6 : LE ROUTAGE
 76

Principes de base du routage IP

Le routage c'est quoi ?
La raison d'être d'IP est bien d'interconnecter des réseaux physiques hétérogénes ou non. Ce
protocole de niveau 3 propose un format de paquets, un format d'adressage et une logique
d'acheminement des paquets entre les réseaux physiques. Cette dernière fonction se
nomme : Le routage

Cette fonction est réalisée, généralement, par des équipements spécifiques appelés des
routeurs. Ces routeurs appliquent tous les mêmes règles de base pour que le transfert des
paquets soit cohérents. Ce sont les règles de routage.

Avec IP, une notion très importante est à connaître : IP route des réseaux pas des machines !

Ceci veut dire, que seule la partie réseau d'une adresse est examinée par les équipements de
routage pour déterminer la direction à prendre. L'acheminement vers la machine est réalisée
par la logique de traitement des paquets appliquée par les machines IP sur le LAN de
destination.

Pour imager le principe du routage, nous allons prendre l'exemple d'un utilisateur (Jules ...
Toujours lui !) qui souhaite afficher une page HTTP d'un serveur distant. Pour simplifier nous
dirons que l'utilisateur tape dans la barre d'adresse du navigateur, l'adresse directe du serveur
à atteindre au lieu d'entrer un nom mnémonique comme www.jebulle.com. Il entre l'adresse
: http://10.0.0.1/site/.

Sortir du LAN

Trouver la sortie du réseau physique

Une application voulant transmettre des données à une autre, va transmettre ses données
aux couches inférieures. Pour notre exemple, le navigateur va transférer l'adresse du serveur
(10.0.0.1) à IP (je vous fait grâce des résolutions de proxy, DNS, TCP et autres ...).
 77

Le stack IP du PC de Jules va examiner l'adresse, et notamment la partie réseau, il va

remarquer que cette adresse n'est pas du même réseau que lui. En effet, l'adresse de Jules est
: 12.0.0.2. Il sait, dans ce cas, qu'il doit envoyer son paquet à un équipement installé sur son
réseau physique (dorénavant nous dirons LAN) qui assure le transfert des paquets à
l'extérieur du LAN. Cet équipement est un routeur (ce pourrait être un serveur type FireWall
! Mais ne compliquons pas les choses !). Dans la terminologie IP on appelle cet équipement
une "Gateway" ou "Passerelle" en français !

Comment le PC de Jules connaît-il l'adresse de la passerelle ? He bien, si l'administrateur du

réseau a bien fait son travail, il a du saisir l'adresse IP de la passerelle dans un champ, appelé
"Passerelle" ou "Gateway Default" (Passerelle par défaut), dans les "Propriétés réseaux" du
PC. Le nom de "Passerelle par défaut", signifie que le PC enverra par défaut à cette passerelle,
tous les paquets qu'il ne sait pas router. Or une machine IP qui n'est pas une passerelle ne
sait pas router des paquets en dehors de son adresse réseau !

Si Jules avait envoyé un paquet à un serveur 12.0.0.1, son PC l'aurait envoyé directement au
serveur, celui-ci étant dans son réseau.
 78

Algorythme de traitement du routage

La passerelle reçoit le paquet à destination de 10.0.0.1. Quel traitement applique-t-elle à ce
paquet ? L'organigramme suivant vous présente la logique appliquée :

La passerelle extrait le paquet IP de la trame niveau 2 et examine le champ d'adresse

destination :

• si le paquet a pour adresse son adresse IP à elle (la passerelle !), le paquet est envoyé
dans les couches hautes vers l'application de la passerelle. Jules tente d'accèder à
l'administration de la passerelle. C'est ainsi que vous pouvez faire un TELNET sur un
routeur par exemple !
• si le paquet a pour adresse un adresse différente de celle de la passerelle, il est envoyé
au module routage. Le module routage examine la partie réseau de l'adresse de
destination du paquet :
 79

1 - si le réseau demandée est le même que celui de provenance du paquet (même réseau
que l'adresse source), la passerelle renvoie le paquet sur l'interface par laquelle elle l'a reçue
et renvoie par la même occasion à la station émettrice du paquet un ICMP Redirect (on en
causera plus tard !).

2 - si le réseau demandée est différent de celui de provenance, elle examine sa table de

routage:

• si dans sa table le réseau existe :

o elle examine le champ TTL et le décrémente de 1. Si elle passe
ainsi le TTL à 0, elle détruit le paquet et émet à la station
émettrice du paquet un ICMP Time Exceded (on en parlera aussi
plus tard !).
o si le champ TTL n'est pas à 0, elle envoie le paquet à la prochaine
passerelle pour le réseau. Cette passerelle est indiquée dans sa
table de routage à coté de l'adresse réseau.
• si le réseau n'existe pas dans sa table :
o elle regarde si sa table propose une route par défaut (0.0.0.0 via
14.0.0.1 sur interface S2). Si elle existe, elle applique le même
traitement sur le TTL que vu précédemment, et envoie le paquet
à la passerelle indiquée.
o si il n'y a pas de route par défaut, elle jette le paquet ! Ni vu ni
connu, je t'embrouille (C'est tout IP ça !), et elle émet un ICMP
Destination Unreachable (j'ai dit, qu'on en parlerai plus tard !) à
la station émettrice.

La passerelle ne prend en compte que des paquets qui lui sont transmis dans des trames
(niveau 2) qui lui sont adressées. Nous reviendrons sur cette notion quand nous parlerons
d'ARP. Pour le moment, admettez que le PC de Jules à réussi à trouver l'adresse niveau 2 de
la passerelle, qu'il a encapsulé le paquet IP d'adresse destination 10.0.0.1 dans cette trame
adressée au serveur.

Pour émettre le paquet à une autre passerelle, celui-ci est bien sûr réencapsulé dans une
trame de niveau 2, correspondante au protocole de couche réseau en vigueur sur le lien
physique de l'interface de sortie de la passerelle.

Table de routage
La table de routage d'une passerelle, nous venons de l'apprendre, ne connaît que les adresses
réseaux du réseau IP auquel elle appartient. Pour réaliser le routage d'un paquet, une
passerelle examine l'adresse destination du paquet, en extrait l'adresse réseau et liste sa table
de routage pour trouver la ligne correspondante.

Sur cette ligne elle trouvera généralement un certain nombre d'indications :

• Source : indique comment la passerelle a appris la route (l'adresse du réseau

destination). Il y a différentes possibilités pour permettre à une passerelle d'avoir
 80

connaissance des réseaux existants : la passerelle est directement connecté au réseau

physique associé au réseau IP. Une de ses interfaces a donc une adresse machine
personnelle dans ce réseau, ce qui lui permet de détecter que le réseau existe.
• l'administrateur du réseau d'interconnexion a déclaré manuellement l'existence de ce
réseau dans la table de routage (on parle de routage statique).
• un protocole de routage (RIP, IGRP, e-IGRP, OSPF, BGP4, etc...) existe entre les
différentes passerelles et leur permet de s'échanger les adresses réseaux que chacune
connait. C'est le routage dynamique. Nous reviendrons sur ces notions de routage
avancées lors d'un cours dédié.
• Adresse réseau : indique l'adresse (partie réseau) du réseau de destination
• Adresse passerelle : si le réseau n'est pas directement connecté à la passerelle (sur
une de ses interfaces), ce champ indique à quelle passerelle il faut passer le paquet
• Interface de sortie : indique sur quelle interface de la passerelle il faut envoyer le
paquet pour lui permettre d'atteindre la machine demandée si le réseau de destination
est directement raccordé à la passerelle, ou pour atteindre la prochaine passerelle, si
le réseau de destination n'est pas directement raccordé.

On trouvera également d'autre champs comme un compteur indiquant depuis quand la

passerelle connaît le réseau, ou comme un indication de coût de route, qui permet de choisir
la route la plus rapide quand il existe plusieurs possibilités pour atteindre une destination.

Et le paquet de Jules ?
Pour notre exemple, le paquet de Jules, émis à destination de 10.0.0.1 est analysé par la
passerelle comme "à destination du réseau 10.0.0.0". La passerelle n'est pas directement
raccordée au réseau 10.0.0.0, elle n'a pas dans sa table de réseau 10.0.0.0 mais a une route
par défaut 0.0.0.0 via 14.0.0.1 (la passerelle X2). Cette passerelle est accessible par l'interface
 81

Série2 de la passerelle X1 (c'est la table de routage qui le dit !). X1 réencapsule le paquet IP
dans une trame HDLC (protocole de niveau 2 du lien série entre X1 et X2 !).

X2 reçoit une trame sur son interface Série0. Comme c'est un lien série, toutes les trames qui
arrivent sur ce lien lui sont forcément adressées. Il récupére donc le paquet IP placé à
l'intérieur et examine l'adresse destination sur le même algorythme que présenté
précédemment. Il en déduit que le réseau à atteindre et le réseau 10.0.0.0. Ce réseau est
décrit dans sa table de routage, comme accessible par la passerelle 15.0.0.1 (X3) sur son
interface Ethernet0. Il réencapsule le paquet dans une trame niveau 2 Ethernet, ayant pour
adresse destination, l'adresse niveau 2 de X3 (je vous passe les détails sur la manière dont X2
a appris l'adresse niveau 2 de X3, mais sachez qu'ARP y est pour quelque chose !).

X3 reçoit une trame qui lui est adressée sur son interface Ethernet2. Il examine son contenu
(Oh ! Joie ! Un paquet IP ! Merci X2 !). Il examine l'adresse destination du paquet, en déduit
qu'il est à destination du réseau 10.0.0.0. Surprise ! Son interface Ethernet0 est justement
dans le réseau 10.0.0.0 ! Comment le sait-il ? Parce que l'adresse IP de son interface Ethernet0
est 10.0.0.254, d'ailleurs dans sa table de routage il voit bien que 10.0.0.0 est annoncé comme
"Connected" sur son interface Ethernet0. Elle est donc dans le réseau 10.0.0.0 ! Il sait donc
que le serveur 10.0.0.1 se trouve quelque part sur ce réseau Ethernet. Il va prendre le paquet
IP et l'encapsuler dans une trame Ethernet (niveau 2, mais vous le savez non ?) à destination
du serveur Web 10.0.0.1 (encore une fois, c'est ARP qui aura indiqué au routeur quelle est
l'adresse niveau 2 du serveur !).

Le serveur reçoit donc une trame qui lui est adressée, contenant un paquet IP qui lui est
également adressé. On remonte donc dans les couches, on interprète le contenu du paquet
IP, puis le serveur répond et on repart dans l'autre sens ... Mais vous en savez assez,
maintenant, pour comprendre comment la réponse sera routée dans le réseau. Examinez les
tables de routage des routeurs sur le schéma !

Conclusion du chapitre
Pas trop dérouté par tout ce routage ? Vous commencez à saisir la logique ?

Retenez donc bien qu'une passerelle route en examinant la partie réseau d'une adresse IP et
pas la partie machine. Retenez également que le routage se fait de proche en proche :

• station vers passerelle de sortie (gateway default + ARP)

• puis de passerelle en passerelle (tables de routage + éventuellement ARP)
• puis de dernière passerelle à station de destination (table de routage + ARP)

Dans le chapitre précédent je vous ai présenté l'adressage IP de base. Vous connaissez tout
des 3 classes principales d'adresses et des adresses spécifiques IP.

Dans ce chapitre nous avons étudié les bases du routage. Il est essentiel de maintenant
comprendre comment définir un plan d'adressage et quels sont les pièges !
 82

CHAPITRE 7 : PLAN D'ADRESSAGE IP

Plan d'adressage IP
Qu'est-ce qu'un plan d'adressage ?
Lorsque vous devez créer un réseau d'entreprise IP, ce réseau interconnectant différents sites
et réseaux de votre société, vous réfléchissez à un plan d'adressage. Cette opération a pour
but de définir pour chaque réseau physique (LAN et WAN) une adresse de réseau IP. Pour
chaque machine de chacun de ces réseaux, vous devrez choisir une adresse machine dans le
réseau IP choisi.

Pour définir la ou les classes d'adresses que vous allez choisir, vous tiendrez compte du
nombre de réseau physique de votre réseau d'entreprise et du nombre de machines sur
chacun de ces réseaux. Vous avez alors différentes possibilités :

• vous choisissez des adresses réseaux IP totalement librement (1.0.0.0, 2.0.0.0, 3.0.0.0, etc.).
Vous définissez ainsi un plan d'adressage privé, mais vous ne vous assurez pas de l'unicité
mondiale des adresses. Autrement dit, si vous envisagez un jour de connecter votre réseau à
Internet, il y a de fortes chances que ces adresses soient déjà attribuées à d'autres sociétés.
Vous aurez alors de sérieux problèmes de routage vers Internet et vous serez obligé de
rectifier le tir de deux façons possibles :
o sur votre point de sortie vers Internet vous placez un équipement (routeur ou
FireWall) qui va modifier "à la volée" vos adresses de machines pour les rendre
compatibles avec le plan d'adressage Internet. Cette fonction de translation d'adresse
est appelée NAT : Network Adress Translation.
o vous redéfinissez complétement votre plan d'adressage avant d'être viré par votre
PDG !
• vous prévoyez votre interconnexion possible avec Internet et, à ce titre, souhaitez être
compatible avec son plan d'adressage. Vous définissez un plan d'adressage conforme au plan
d'adressage public. Pour cela, vous demandez à des organismes spécifiques (NIC, AFNIC ou
votre IAP : Internet Access Provider) des adresses IP publiques qui vous seront réservées. Avec
ces adresses réseaux vous définirez votre plan d'adressage interne. Le problème de cette
solution est qu'il y a une très grosse pénurie d'adresses IP publiques ! C'est d'ailleurs une des
raisons qui a conduit à redéfinir une nouvelle version du protocole IP, l'IP V6, qui propose un
format d'adressage sur 16 octets ! Vous aurez donc très peu d'adresses, et si votre réseau est
important vous risquez d'être coincé !
• la dernière solution est d'utiliser des adresses dites non routables. Ce sont des adresses
réseaux spécifiques qui ne sont et ne seront jamais utilisées sur Internet. Vous êtes ainsi sûr
de ne pas avoir de conflit d'adressage. Ces adresses sont définies par une RFC spécifique, la
RFC 1918.

L'objectif de ce chapitre est donc de vous présenter ces quelques concepts de définition des
plans d'adressage.

Problématique de l'interconnexion avec Internet

 83

IP a été conçu pour interconnecter des réseaux au niveau mondial. Il est notamment
implémenté sur Internet. On peut concevoir facilement qu'il est impératif que deux serveurs
ou deux réseaux d'entreprises raccordés à Internet n'est pas la même adresse. Sinon, il y aura
un conflit de routage (vous aimeriez que votre voisin reçoive votre courrier ?).

Chaque I.A.P (Internet Access Provider : TRANSPAC, WORDLCOM, C&W, etc.) dispose d'un
"pool" d'adresses IP (réseau et à fortiori donc machine !) qu'ils peuvent affecter à des clients
qui leur demande un accès Internet. Ces adresses sont attribuées par des organismes très
sérieux qui veillent à la cohérence du plan d'adressage Internet : unicité des adresses,
répartition géographique des "pools" contigus (le fameux CIDR pour les érudits !). Ces
organismes s'appellent le NIC (Network Information Center), l'AFNIC, TRANSPAC, etc. On les
appelle des "registrar".

Cependant le plan d'adressage IP, même s'il est copieux, n'autorise pas un nombre infini
d'adresses réseaux ou machines. En conséquence, lorsqu'une entreprise veut connecter son
réseau à Internet, elle n'obtient pas autant d'adresses qu'elle le souhaiterai. En effet, il y a
actuellement une pénurie d'adresses publiques, notamment en classe A et B. Ces deux classes
sont les plus recherchées car elles offrent de plus grandes possibilités en nombre de machines
et, vous le verrez plus tard, en définitions de sous-réseaux. Cette pénurie a conduit, pour
partie, à la définition d'une nouvelle version d'IP, l'IP V6, qui offre, notamment, un adressage
sur 16 octets (Demain, toutes les cafetières du monde pourront avoir leur adresse IP !!).

Revenons à notre entreprise qui réclame des adresses publiques pour créer son plan
d'adressage interne. Lorsqu'elle fera la demande d'adresses, il faudra qu'elle justifie de son
besoin. Et sachez que l'argument "Je veux donner une adresse publique à tous mes utilisateurs"
est un MAUVAIS argument ! On lui répondra "Et la NAT vous connaissez ?" et on ajoutera "Et
la RFC 1918 vous connaissez ?", pour finir on lui dira "Si vous ne connaissez pas, allez lire le
cours IP à l'adresse http://www.gatoux.com/ et revenez nous voir quand vous aurez compris
!". Finalement on lui donnera, généreusement, 8 adresses machines et débrouille-toi !

N.A.T sauve moi !

N.A.T pour Network Address Translation (rien à voir avec le diminutif de Nathalie !) permet
de "translater" une adresse IP en une autre. Plus fort ! Il existe deux formes de NAT :

• le "natage" (mon dieu quelle horreur !! Promis je le ferai plus !), la translation d'adresse source
qui consiste à modifier l'adresse source d'un paquet IP en une autre adresse. Par cette
technique on dit souvent que l'on masque le plan d'adressage interne. En effet, tout paquet
qui franchi l'équipement effectuant la NAT (routeur, FireWall ou Proxy) part avec une adresse
source différente de la vraie adresse source de l'émetteur. Un observateur extérieur (pour ne
pas l'appeler un "hacker" ou "pirate" !!) ne verra donc qu'une adresse affectée par translation
ne correspondant pas à une réelle adresse de l'émetteur. Généralement l'adresse affectée est
celle de l'interface de sortie de l'équipement qui assure la translation.
 84

• la translation d'adresse destination, moins courante, permet de modifier l'adresse

destination d'un paquet IP lorsque celui-ci demande une adresse spécifique. Vous pouvez, de
cette manière, masquer l'adresse réelle d'un serveur au monde extérieur ! Les internautes
cherchent, par exemple, à contacter l'adresse 132.12.12.11 qui correspond en fait à votre
adresse de FireWall (Pare-Feu). Le FireWall à réception des paquets va modifier l'adresse en
10.0.0.1 qui est l'adresse interne de votre serveur ! De cette façon on ne peut pas joindre votre
serveur sans passer par votre FireWall ! Bien sûr, lors de la réponse du serveur, le FireWall
modifiera l'adresse source de réponse !

La N.A.T permet de n'utiliser qu'une seule adresse machine coté Internet. Cette adresse est
affectée à l'interface de sortie de l'équipement réalisant la NAT. Tous les paquets, de tous les
utilisateurs internes, partiront sur Internet avec cette adresse source. Mais bien sûr les
réponses des serveurs sur Internet se feront toutes vers l'adresse source indiquée dans le
paquet qu'ils recoivent, c'est à dire celle de l'équipement qui assure la N.A.T !

Dans ce cas, comment faire pour que les réponses arrivent bien à chaque machine qui a émis
initialement la requête ? C'est assez simple ... L'équipement N.A.T va maintenir une table de
correspondance des translations en cours !

Lorsqu'une station envoie un paquet IP vers l'extérieur, il mémorise l'adresse source interne
de la station et l'adresse destination externe demandée. Ce couple est insuffisant car lors des
réponses l'équipement disposera toujours de la même adresse destination (la sienne !), il ne
peut donc pas déterminer à qui il doit réémettre le paquet. De la même manière, s'il se baset
sur l'adresse source du paquet, il pourra retrouver la correspondance d'adresse de la staiton
initiale mais seulement si une seule station discute avec le serveur ! Si plusieurs stations
discutent avec le même serveur externe il ne peut pas savoir à laquelle retransmettre le
paquet. Il doit donc mémoriser des informations supplémentaires pour identifier de manière
unique un couple station_interne - serveur_externe de manière unique.

Il mémorise donc également les ports source et destination du segment TCP ou UDP véhiculé
par le paquet IP. Pour une machine IP donnée le couple @IP-N° Port Source est toujours
 85

unique ! Le sujet du cours n'étant ni TCP/UDP ni la N.A.T nous ne pousserons pas plus loin !
Croyez-moi sur parole si vous n'avez rien compris à la démonstration précédente.

L'équipement de NAT mémorise donc la correspondance :

adresse source interne - port tcp source - adresse destination demandée - port tcp destination.

Au retour des paquets il examinera les couples adresses sources, ports TCP (destination et
source) et pourra retrouver l'adresse destination à donné au paquet pour qu'il soit routé en
interne !! Compris ?

Tout cela pour vous faire comprendre que rien n'oblige une entreprise à mettre en place un
plan d'adressage IP public (avec des adresses attribuées par un "registrar" ou obtenues auprès
du NIC directement par l'entreprise). En effet :

• si l'entreprise n'a pas l'attention d'interconnecter son réseau avec Internet, elle n'est pas
obligé de respecter son plan d'adressage ! Mais attention si son besoin évolue ! Car refaire un
plan d'adressage complet d'un réseau d'entreprise est loin d'être anecdotique ! Vous jouez
votre place sur ce coup là !
• même si elle veut interconnecter son réseau avec Internet, nous venons de voir, que
l'activation de la NAT sur le routeur d'interconnexion, permettra de masquer le plan
d'adressage interne et de se mettre en conformité avec le plan d'adressage Internet.

Donc la NAT c'est la solution à tous vos soucis ? Presque ... Attention, le loup veille dans le bois
...

Le loup dans le bois !

Un loup bien caché !

Imaginons qu'une entreprise mettent en place un réseau IP interne sans respecter le plan
d'adressage Internet. Elle souhaite, tout de même, s'interconnecter avec Internet, mais pense
que la NAT sur le routeur d'accès résoudra tous les problèmes ... C'est faux !
 86

Supposons qu'elle crée un réseau 128.10.0.0 sur lequel elle installe son serveur d'application
(la paye par exemple ! C'est beau un serveur de paye, non ?), ayant pour adresse 128.10.11.2
! Maintenant supposons qu'un utilisateur, Jules (toujours lui !), du réseau veuille surfer sur
Internet et notamment atteindre le serveur www.jebulle.com ! Après résolution DNS (désolé,
mais DNS ce sera pour un autre jour !) le PC de Jules est informé que le serveur en question
est à l'adresse : 128.10.11.2 !! Vous sentez le problème ? C'est l'adresse du serveur de paye !
A votre avis ? Jules atteindra-t-il le serveur www.jebulle.com ? Suspense ....

He bien, non !! Il ira sur le serveur de paye !! Et pourquoi ? Parce que les routeurs internes au
réseau de l'entreprise qui interconnectent les différents réseaux locaux (LAN : Ethernet, Token
Ring, etc...) connaissent un réseau interne 128.10.0.0 et envoient le trafic vers ce réseau ...

En fait, dans tous les réseaux d'entreprises, lorsqu'ils sont interconnectés à Internet, on
applique la méthode du routage par défaut vers Internet. Cela veut dire que quand un routeur
interne ne connaît pas précisément une adresse réseau demandée en destination, il va
envoyer le paquet sur une route par défaut (0.0.0.0 : vous vous souvenez ?), qui généralement
correspondra au routeur de sortie, d'interconnexion avec Internet. Le routeur de sortie vers
Internet aura les moyens d'acheminer ce paquet vers www.jebulle.com (là, je vous passe les
détails ... Il faut bien s'arrêter quelque part !), et pourra également appliquer la NAT si vous le
désirez. Mais encore faut-il l'atteindre !

Donc si on veut enclencher le routage par défaut au niveau des routeurs internes, il faut que
les adresses de serveurs Internet ne puissent jamais correspondre à des adresses de serveurs
internes à l'entreprise ! Pour être plus précis, étant donné que les routeurs ne connaissent
que des adresses réseaux et pas machines, il faut que l'adresse réseau du service demandé
sur Internet, ne corresponde jamais à une adresse réseau interne à l'entreprise !

En conséquence, si vous n'avez pas cherché à être en conformité avec le plan d'adressage
Internet en pensant que la NAT vous sortira de toutes les situations, c'est perdu ! Vous courrez
à la catastrophe, NAT ou pas NAT !

D'accord mais on vous a dit que le plan d'adressage IP public est saturé ! On vous a dit que
vous n'obtiendrai jamais assez d'adresse IP normalisée pour adresser tous vos réseaux
internes ! Comment faire ?

RFC 1918, sauve moi !

La RFC 1918 vient à votre secours ! Cette RFC défini un "pool" d'adresse IP réseaux dites "non
routables". C'est à dire, que le NIC (et l'IETF) garanti qu'aucun serveur sur Internet n'utilisera
ces adresses réseaux ! On appelle également ces adresses des adresses IP privées.

Si un petit génie vous pose la question suivante (Je sais ! Moi-même, je la pose souvent ! Suis-
je donc un génie ?) :

• Etes-vous conforme à la RFC 1918 ?

 87

Ne le regardez plus avec des yeux ronds ! Si vos adresses IP internes sont conformes à celles
que je présente ci-dessous, vous pouvez répondre "Oui", sinon ...

Liste des adresses réseaux non routables :

• toutes les adresses du réseau 10.0.0.0 (Classe A)

• toutes les adresses des réseaux 172.16.0.0 à 172.31.0.0 (Classe B)
• toutes les adresses du réseau 192.168.0.0 à 192.168.255.0 (Classe C)

Si votre plan d'adressage interne est établi sur ces adresses, vous n'aurez aucun problème de
routage par défaut vers Internet. Utilisez ces adresses et faites de la NAT pour sortir sur
Internet avec les quelques adresses normalisées que votre IAP vous aura généreusement
attribué !

Mais ces quelques adresses "privées" RFC 1918 suffiront-elles à adresser l'ensemble de vos
réseaux et machines ? Probablement que oui ... Mais vous avez aussi la ressource des sous-
réseaux pour définir plus de réseaux ! Nous y arrivons enfin !

Qu'est-ce qu'un sous-réseau ?

Les sous-réseaux sont des sous-répartitions d'un réseau. Nous savons :

• qu'une adresse IP est formée d'une partie réseau et d'une partie machine
• qu'on affecte une adresse réseau à chaque réseau physique

Si chaque réseau physique comporte moins de stations que ne peut en définir la partie
machine de l'adresse réseau affectée, on gaspille des adresses !

On va dans ce cas utiliser une partie des bits machines de la partie machine de l'adresse pour
étendre la partie réseau de l'adresse. En ajoutant ces bits à la partie réseau on se donne plus
de possibilités d'adresses réseaux. Cependant on sort dans ce cas du cadre normalisé des
Classes A, B ou C ! La partie ajoutée est donc considérée comme une sous-répartition de
l'adresse réseau dans sa classe initiale. C'est le sous-réseau !

Utilité des sous-réseaux

Les sous-réseaux ont essentiellement deux cadres d'utilisation :

• permettre de "tronçonner" une plage d'adresse normalisée (conforme à Internet) trop juste
pour affecter une adresse réseaux par réseau physique de l'entreprise.
• permettre dans les grands réseaux, une optimisation du routage, en diminuant le nombre de
réseaux déclarés dans les tables de routage des passerelles.
 88

Cas du "tronçonnage" !

Si une entreprise désire créer un réseau interne complet, sur un plan d'adressage dit "public"
(en cohérence avec celui d'internet), nous savons maintenant qu'elle ne disposera pas d'une
infinité d'adresses réseaux. Il faudra qu'elle ruse pour définir chacun de ses réseaux physiques
(Ethernet, Token Ring, Liaisons Louées) avec une seule adresse réseau (voir avec une partie
d'adresse réseau) fourni par son IAP !

Dans ce cas, elle va tronçonner son adresse réseau en sous-réseaux pour définir un sous-
réseau par réseau local (LAN) par exemple. Bien sûr cette technique limitera le nombre de
machines qu'elle pourra installer sur chaque réseau physique, mais bien souvent ce n'est pas
un problème.

Cas de l'optimisation du routage !

A votre avis ? L'optimisation du routage c'est quoi ? Ci-dessous, le schéma d'un réseau privé
faisant appel à un plan d'adressage standard de classe A. Chaque routeur connaît l'ensemble
des réseaux :

Supposons qu'un réseau soit "subnetter" (humm.. Joli mot !) en 10 sous-réseaux. Si le routeur
connaît les dix sous-réseaux il aura dix lignes dans sa table de routage (rappelez-vous le
chapitre précédent).

Mais nous savons maintenant que les sous-réseaux font partie d'une même adresse réseau.
Donc si on localise dans un même endroit du réseau l'ensemble des sous-réseaux d'un réseau,
les routeurs à l'extérieur de cette concentration pourront considérer l'ensemble de ces sous-
 89

réseaux comme un seul réseau. Le schéma suivant propose de remplacer les réseaux 11.0.0.0,
12.0.0.0 et 13.0.0.0 par des sous-réseaux d'un réseau 11.0.0.0. Le routeur externe n'a plus que
deux lignes dans sa table de routage. Il identifie le réseau 11.0.0.0 dans sa globalité, charge au
routeur interne de traiter la séparation en sous-réseaux.

Si un routeur externe à cette concentration envoie un paquet au routeur interne à la

concentration il atteindra forcément le sous-réseau, le routeur de la concentration se
chargeant de router vers les bons sous-réseaux. Il suffit alors d'avoir une seule entrée dans la
table de routage du routeur externe, celle du réseau, le routeur interne aura lui une entrée
pour chaque sous-réseaux.

Avec une telle structure d'adressage, vous hiérarchisez votre routage et allégez vos tables de
routage. Un routeur n'aime pas les grosses tables de routage, moins il a d'entrée dans la table,
moins il a de lignes à scruter, plus il commute rapidement et moins de mémoire il lui faut !

Bien sûr il faudra bien qu'à un endroit, un routeur ait connaissance des sous-réseaux (le
routeur de concentration) pour faire la séparation du trafic, mais plus ce routeur est prêt de
la destination moins les autres ont à connaître de routes.

Pour la petite histoire, ce concept est tellement important dans les grands réseaux et
notamment pour Internet qui route des millions de réseaux, qu'un protocole appliquant ce
principe au niveau des adresses réseaux consécutives a été produit. Ce protocole s'appelle le
CIDR (Classless InterDomain Routing). Ce protocole permet de regrouper sur le plan du
routage des adresses réseaux consécutives 1.0.0.0, 2.0.0.0, 3.0.0.0 etc. en considérant une
seule route pour le groupe. On raméne donc à une entrée de table de routage au lieu des 3
de notre exemple. Il faut bien sûr que ces réseaux soient regroupés "géographiquement".
C'est d'ailleurs la logique qui essaie (j'ai bien dit essaie !) d'être respectée sur Internet avec
des blocs consécutifs pour la plaque Europe, pour la plaque Asie, etc.

Conclusion du chapitre
 90

Alors, à votre avis ? L'architecture réseau c'est facile ? Rassurez-vous on s'y fait très vite. Mais
ce chapitre avait pour but d'introduire quelques éléments de base et fondamentaux pour
construire un bon plan d'adressage. Je l'ai réécris plusieurs fois pour essayer d'être à la fois le
plus simple et le plus logique possible. J'espère avoir réussi ! Il était difficile, à mon sens,
d'introduire la notion des sous-réseaux sans passer par les bases d'un plan d'adressage.

Vous avez maintenant des notions de routage, des notions d'adressage avec des standards
comme la NAT ou la RFC 1918. Il vous manque un dernier point pour conclure ces chapitres
sur l'adressage IP :

• comment créer des sous-réseaux

• comment identifier un sous-réseau

Sous-réseaux et masques IP
Rappels
Dans les chapitres précédents nous avons abordé les notions de classes d'adresses IP, de
routage et de plan d'adressage. Nous avons également présenté au moins deux cas de
justification d'utilisation des sous-réseaux ainsi que le concept général du sous-réseau. Celui-
ci, pour rappel, est une sous-répartition d'une adresse réseau standard définie à l'aide de bits
inutilisés dans la partie machine de l'adresse IP.

Nous avons vu qu'une adresse IP "standard" comportait une partie réseau (appelée aussi "net-
id") et une partie machine (appelée aussi "net-host"). Le principe est donc de "gratter"
quelques bits de la partie machine pour définir une sous répartition de la partie réseau.
L'adresse aura donc trois parties :

• la partie réseau définie sur 1, 2 ou 3 octets selon sa classe

• la partie sous-réseau définie sur X bits
• et la partie machine définie sur 3, 2 ou 1 octets (selon la classe de l'adresse) moins les X bits
de la partie sous-réseau

Notations
Jusqu'ici, pour définir une adresse IP générique j'utilisais la notation R.R.M.M (pour une classe
B par exemple), où R représente la valeur décimale d'un octet réseau et où M représente la
valeur décimale d'un octet machine. Nous allons enrichir cette notation pour pouvoir définir
l'adresse générique jusqu'au bit ! Ainsi "r" représentera la valeur binaire d'un bit d'un octet
réseau, "s" pour les bits sous-réseaux et enfin "m" pour les bits machines. Donc, selon cette
notation, une adresse standard de classe B sera notée :

• R.R.M.M = rrrrrrrr.rrrrrrrr.mmmmmmmm.mmmmmmmm
 91

Supposons maintenant que je dispose de l'adresse, classe B, 128.10.0.0, nous obtiendrons la

notation suivante :

• 128.10.0.0 = 10000000.00001010.00000000.00000000

Pour gagner un peu de temps en écriture, j'aurais pu aussi la représenter tel que :
128.00001010.M.M ou 128.00001010.0.0 ! Nous mélangerons allégrement toutes les
notations (décimales, binaires et génériques) mais maintenant que les accords de notation
sont fixés, nous nous comprenons n'est-ce pas ? Bien sûr ces notations ne sont pas standard
et ne sont à considérer que dans le cadre de ce cours, pour faciliter votre compréhension !

Logique de définition des sous-réseaux

ll est maintenant temps d'entrer dans le vif du sujet ! Le problème se pose généralement ainsi
:

• j'ai une ou deux adresses réseaux IP de classe X

• j'ai 10 réseaux physiques et 40 machines par réseau
• quels sous-réseaux dois-je définir pour interconnecter ces réseaux et machines ?

Supposons que vous ayez les adresses 10.0.0.0 (classe A) et 192.168.1.0 (classe C). Vous
remarquerez que ces deux adresses sont "non routables", vous êtes donc conforme à la RFC
1918.

Vos 10 réseaux physiques sont interconnectés par des liaisons louées raccordées à des
routeurs à chaque extrémité. Vous avez donc 9 liaisons louées, considérées par IP comme des
réseaux physiques. Sur chacune de ces liaisons les routeurs d'extrémités doivent avoir une
adresse IP sur l'interface raccordée à la liaison. Il vous faut donc en plus de vos sous-réseaux
pour vos 10 LAN, 9 sous-réseaux pour vos liaisons louées supportant chacun deux adresses
machines.

Votre logique sera la suivante (du moins je vous le conseille !) :

• Vous créez des "subnets" sur l'adresse réseau de classe C pour les affecter aux liaisons louées.
En effet l'adresse de classe C est celle qui présente le moins de place pour la partie machine,
mais vous ne dépasserez jamais 2 adresses machines par liaison louée ! Par contre votre réseau
pouvant éventuellement s'étendre à de nouveaux LAN (ou sites), vous allez prévoir une
extension possible du besoin en sous-réseaux pour vos liaisons louées.
• Vous créez des subnets sur l'adresse réseau de classe A pour les affecter à vos LANs. En effet,
l'adresse de classe A est celle qui présente le plus de place pour définir des machines (3 octets
!). Vous avez donc, potentiellement, la possibilité de placer 16 millions de machines sur le
réseau 10.0.0.0. Si vous le découpez vous pouvez prévoir, par exemple (et en théorie), 256
sous-réseaux (un octet de la partie machine) supportant chacun 65 536 machines (les deux
derniers octets de la partie machine). Vous avez ainsi la possibilité d'ajouter de nouveaux sous-
réseaux (LAN ou sites) puisqu'actuellement vous n'en utilisez que 10 sur les 256 disponibles et
sur chacun des sous-réseaux vous avez la possibilité de mettre bien plus de machines que vos
40 initialement prévues.

A ce stade, votre politique d'adressage est définie ! Bravo !

 92

Calcul des sous-réseaux

Premiere partie : Adressage des LANs

Nous venons de choisir le premier octet machine pour définir des sous-réseaux et les deux
derniers octets pour définir les machines de chaque sous-réseau. Le format d'adresse sera
donc le suivant :

• R.ssssssss.M.M soit R.R.S.M.

Les valeurs possibles pour l'octet S de sous-réseau vont donc de 0 (00000000) à 255
(11111111). Vous disposez apparemment donc de 256 sous-réseaux. Est-ce bien sûr ?

• Quelle est l'adresse du premier sous-réseau ? ... Celle qui a tous les bits "s" à 0, soit S=0. Pour
définir une adresse sous-réseau, comme pour une adresse réseau, il faut également mettre
tous les bits de la partie machine à 0. Donc l'adresse réseau du premier sous-réseau sera
10.0.0.0 ! Mais cette adresse est celle du réseau général ! On ne peut pas l'utiliser. Donc avec
8 bits "s", vous ne pouvez, en principe, définir que 255 sous-réseaux (256 combinaisons mois
une !).
• Quelle est l'adresse du dernier sous-réseau ? ... Celle qui a tous les bits "s" à 1, soit S=255, ce
qui donne l'adresse 10.255.0.0. Mais ! Rappelez-vous la notion d'adresse de diffusion dirigé
dans le chapitre 5 ... Pour adresser toutes les machines d'un même réseau, on place à 1 tous
les bits de la partie machine. Cette logique est la même pour les sous-réseaux. Quelle sera
donc l'adresse de "broadcast" du dernier sous-réseaux ? ... Celle ayant tous les bits de la
partie machine à 1, soit la valeur 255 pour les deux derniers octets. L'adresse sera donc :
10.255.255.255. Mais c'est l'adresse "broadcast" du réseau général 10.0.0.0 ! On ne peut donc
pas utiliser le sous-réseau 10.255.0.0 car son "broadcast" correspondrait à celui du réseau
général ! Donc avec 8 bits vous ne pouvez pas définir 256 sous-réseaux, vous ne pouvez pas
définir 255 sous-réseaux, vous ne pouvez définir que 254 sous-réseaux !

En vérité, quelque soit le nombre de bits que vous utiliserez pour définir des sous-réseaux,
les valeurs tout à 0 pour ses bits et les valeurs tout à 1 seront interdites. Vous disposerez
donc de 2N - 2 possibilités !

Pour notre exemple nous disposons donc de 254 sous-réseaux dont les adresses vont de
10.1.0.0 à 10.254.0.0 !

Deuxième partie : Adressage des WANs (Liaisons louées)

Il s'agit ici de définir, sur l'adresse de Classe C fournie une répartition de bits de sous-réseaux
qui permettent de définir un maximum de sous-réseau avec la possibilité de mettre au plus
deux machines sur chacun d'eux (un routeur à chaque extrémité de la liaison).

Sur une adresse de classe C seul le dernier octet est disponible pour adresser les machines, il
faudra, en plus, définir des bits de sous-réseaux sur cet octet. En théorie si on utilise un bit
seulement pour la partie machine, on disposera de deux combinaisons (0 et 1) permettant de
définir les deux machines. Mais, depuis le chapitre 5, nous savons que les adresses machines
0 et 255 sont impossibles (adresse réseau et broadcast). Nous avons démontré que N bits
machines définissez 2N - 2 machines ! Si on ne prend qu'un bit machine on ne pourra donc
 93

définir aucune machine (21-2 = 2-2 = 0). Il faut donc au minimum 2 bits machines qui définirons
22-2 = 4-2 = 2 machines. Ces bits seront les deux derniers de l'octet machine de la classe C. Les
6 premiers bits seront donc des bits de sous-réseaux, on aura le format suivant :

• R.R.R.ssssssmm

Vous remarquez que nous ne sommes pas obligé de prendre tout un octet pour définir des
sous-réseaux !

• Le premier sous-réseau sera celui ayant la combinaison ssssss = 000001 (000000 : est
impossible en regard de la démonstration du paragraphe précédent).
• Le dernier sous-réseau sera celui ayant la combinaison ssssss = 111110 (111111 : est
impossible en regard de la démonstration du paragraphe précédent)

Pour définir des réseaux et sous-réseaux on place la partie machine à 0, donc les bits "mm" à
0. Les combinaisons finales sont donc :

• 192.168.1.00000100 = 192.168.1.4
• 192.168.1.11111000 = 192.168.1.248

Pour chaque sous-réseau les deux adresses machines possibles sont les combinaisons "01" et
"10" sur les bits "mm". On obtient donc les adresses suivantes pour les machines du premier
sous-réseau :

• Machine 1 : 192.168.1.00000101 = 192.168.1.5

• Machine 2 : 192.168.1.00000110 = 192.168.1.6

Les adresses de diffusion (broadcast) sur ces deux sous-réseaux sont les combinaisons "11"
sur les bits "mm". On obtient donc les adresses "broadcast" suivantes pour le premier et le
dernier sous-réseau :

• Premier sous-réseau : 192.168.1.00000111 = 192.168.1.7

• Dernier sous-réseau : 192.168.1.11111011 = 192.168.1.251

Le tableau suivant présente les adresses réseaux, machines et broadcast pour les 5 premiers
sous-réseaux. Pour vous entraîner vous pouvez essayer de trouver ces adresses pour les X
autres sous-réseaux (une barre de chocolat au premier qui trouve la valeur de X !).

Sous-réseau
Machine 1
Machine 2
Broadcast
192.168.1.4
192.168.1.5
192.168.1.6
192.168.1.7
192.168.1.8
192.168.1.9
192.168.1.10
192.168.1.11
 94

192.168.1.12
192.168.1.13
192.168.1.14
192.168.1.15
192.168.1.16
192.168.1.17
192.168.1.18
192.168.1.19
192.168.1.20
192.168.1.21
192.168.1.22
192.168.1.23

La question qui tue !

Maintenant vous êtes heureux ! Vous savez calculer des sous-réseaux ! Si ça se trouve, vous
trouvez même ça facile ! Je ne supporte pas votre air béat ! Je vais donc figer sur vos faces ce
stupide sourire satisfait ! Question ... :

• Comment une machine fait-elle pour savoir qu'elle se trouve dans le sous-réseau 192.168.1.4
quand on lui donne l'adresse 192.168.1.5 ?

Vous n'êtes pas sans savoir qu'il est important pour elle de savoir dans quel réseau ou sous-
réseau elle se trouve puisque selon le cas, elle transmettra ses paquets directement à la
station destinataire ou à la passerelle ! Or nous savons qu'elle peut repérer son réseau par la
valeur du premier octet qui défini la classe d'adresse et donc la portée des octets réseaux.
Mais comment peut-elle deviner que vous avez étendue la partie réseau en "grignotant" des
bits machines pour définir du sous-réseau ?

Le masque qui sauve !

Heureusement que Zorro est là ! La machine n'a absolument aucun moyen de savoir si vous
avez défini des sous-réseaux rien qu'en scrutant son adresse ! C'est pourquoi vous allez devoir
l'informer de la portée réelle des octets réseaux dans son adresse. Pour cela vous allez lui
donner une information supplémentaire, qu'on appelle le masque !

Le principe est simple ! Vous allez ajouter une information qui ressemble à une adresse IP mais
qui a un format spécial. Dans cette fausse adresse :

• vous placer à 1 tous les bits qui, dans l'adresse initiale, définissent le réseau et le sous-réseau.
• vous placer à 0 tous les bits qui, dans l'adresse initiale, définissent la machine.

La machine, en superposant son masque sur son adresse, pourra ainsi repèrer la portée des
bits réseaux et sous-réseau.

Par exemple, le masque IP d'une adresse de Classe A standard (sans sous-réseaux) aura tous
les bits du premier octet à 1 puisque seul le premier octet d'une adresse classe A, défini des
bits réseaux :
 95

• Adresse classe A : R.M.M.M

• Masque classe A : 11111111.M.M.M = 255.M.M.M

Si nous reprenons nos deux exemples précédents, les masques se définissent comme suit.

Adresses des LANs

Nous utilisions une classe A avec le deuxième octet réservé à la définition des sous-réseaux.
Le masque associé doit donc couvrir (masquer !) les deux premiers octets réseau :

• Adresse sous-réseau : 10.ssssssss.M.M

• Masque associé : 11111111.11111111.0.0 = 255.255.0.0

Lorsque vous fixez une adresse à une machine, vous lui donnez également son masque. Par
exemple, pour la machine 2 du sous-réseau 5, vous indiquerez:

• Adresse machine : 10.5.0.2

• Masque : 255.255.0.0

Ainsi la machine sait qu'elle est dans le sous-réseau 10.5.0.0 et non pas dans le réseau 10.0.0.0
!

Adresse des WANs

La logique est la même, nous avons utilisé 6 bits du dernier octet pour définir des sous réseau
:

• Adresse sous-réseau : 192.168.1.ssssssmm

• Masque associé : 11111111.11111111.11111111.11111100 = 255.255.255.252

Le dernier octet du masque à la valeur 252 car seuls les 6 premiers bits de l'octet sont à 1. Les
deux derniers bits définissant les machines, ils sont à 0 !

Par exemple, pour la machine 1 du sous-réseau 5, vous indiquerez :

• Adresse machine : 192.168.1.21

• Masque : 255.255.255.252

Et voilà ! Vous savez tout des sous-réseaux et masques !

 96

Exemple de notation

Accords de notations standards

Un architecte réseau va dresser des plans d'adressages dans des tableaux, il va faire des
schémas de réseaux pour imager l'architecture finale. Pour chacune de ces opérations il faudra
qu''il soit en mesure d'afficher le plan d'adressage selon une notation standard
compréhensible par tout le monde.

Dans les schémas précédents de ce cours, j'ai souvent indiqué les adresses machines en entier
avec une petite fléche dirigé vers l'interface à laquelle elle était associée. Cette notation est
lourde et surcharge les schémas.

Il existe donc des accords de notation :

• Une adresse IP doit toujours être indiquée avec son masque, qu'elle soit "subnettée" ou pas.
• L'adresse réseau ou sous-réseau est affectée au réseau physique
• L'adresse machine est indiquée à coté de l'interface sans la partie réseau. En effet on a déjà
la partie réseau indiquée par l'adresse réseau associée au réseau physique.

Il existe deux accords pour indiquer un masque associé à une adresse :

• Indication littérale du masque. Exemple : 14.0.0.0 / 255.0.0.0 ou 192.168.1.20 /

255.255.255.252. Le masque fait apparaître clairement la valeur décimale de chaque octet.
• Indication contractée. Exemple : 14.0.0.0/8 (pour un masque 255.0.0.0) ou 192.168.1.20/30
(pour un masque 255.255.255.252). Le /n indique le nombre de bits réseaux et sous-réseaux
dans l'adresse. Cette deuxième forme est aujourd'hui la plus usitée.

Conclusion du chapitre
Et voilà ! Ce chapitre conclu cette longue, longue présentation de l'adressage IP. Vous vous
sentez soulagé ? Rassurez-vous, le plus dur reste à venir !
 97

Vous savez maintenant, en théorie, mettre en place un plan d'adressage IP, dit de niveau 3.
Vous devez être en mesure d'éviter les pièges courants et vous comprenez enfin à quoi
correspondent les chiffres dans les "Propriétés réseaux - Protocole IP" de votre PC.

Dans le chapitre suivant (pour se reposer) nous allons descendre d'une couche, pour étu

CHAPITRE 9 : ARP QUI EST-TU ?

ARP : A quoi tu sers ?

Introduction
Dans les chapitres précédents nous avons étudié l'adressage IP et les notions de base du
routage. A plusieurs reprises mes schémas présentaient des réseaux locaux (LAN : Local Area
Network) nommés Ethernet et raccordés à des routeurs.

Sur certains schémas j'ai fait apparaître des trames de niveau 2 qui véhiculaient des paquets
IP. Ces trames comportaient à priori une adresse niveau 2 ! Enfin j'ai plusieurs fois fait allusion
à ARP qui permettrait de faire correspondre l'adresse de niveau 2 avec celle de niveau 3 !

Si vous êtes novices ou débutants vous avez probablement dû me haïr et me mettre au rang
des mauvais formateurs qui font exprès de parler de trucs que vous connaissez pas sans vous
éclairer, pour se donner un air intelligent ! Peut-être même que vous n'en avez pas dormi !

Je m'en veux de vous laisser dans cet état, et je ne supporte pas qu'on me haïsse ! Alors je vais
tout vous dire ... Fini les insomnies !

Dans ce chapitre, pour comprendre l'utilité d'ARP nous aborderons rapidement la notion de
réseau local et d'adresse de niveau 2, puis nous étudierons le rôle d'ARP, ses mécanismes de
fonctionnement et son format de paquet. Enfin, si vous êtes sages, nous aborderons
également la notion de Proxy-ARP (ha ! ha ! Vous la connaissiez pas celle-là, hein ?).

C'est quoi un LAN ?

Un LAN est un RLE (je sais ! j'exagère !). Un LAN, pour Local Area Network est, comme son
nom anglais l'indique, un réseau d'aire locale, ou plutôt un Réseau Local d'Entreprise (RLE).
C'est à dire un réseau qui à une couverture géographique très limitée, généralement celle
d'un site ou d'un batiment.

Caractéristiques

Le but de ce cours n'étant pas de présenter les LANs je citerai leurs caractéristiques
essentielles :
 98

• couverture géographique faible (je viens de le dire !)

• hauts débits de transmission (plusieurs Méga bits par seconde : Mbps). Leur faible couverture
géographique permet d'installer des supports physiques d'excellente qualité (affaiblissement
faible, peu de diaphonie et paradiaphonie, bande passante élevée) pour la transmission de
données. Ces supports sont de la paire torsadée (L120, catégorie 5, etc.), de la fibre optique
ou du câble coaxial (de plus en plus rare !).
• réseau de diffusion (avant l'arrivée des switchs je sais ...Mais une chose à la fois ! Pensez à
ceux qui n'y connaissent rien !). C'est à dire que toute donnée émise sur le réseau est vue par
tous les connectés. Lorsqu'une station envoie une trame de niveau 2 (rappelez-vous le modèle
OSI ! Sur un support physique on implémente une procédure de niveau 2), cette trame est
diffusée à toutes les stations présentes sur le réseau local. Cette opération est facilitée par la
topologie logique (et éventuellement physique) du réseau. Les stations sont connectés à un
bus ou à un anneau (pour 99% des cas !). On dit que les réseaux locaux fonctionnent sur des
supports partagés. Cette caractéristique est extrêmement importante car c'est elle qui oblige
à la mise en place d'un adressage au niveau 2.
• méthode d'accès au support. Chaque type de LAN met en oeuvre une procédure particulière,
et normalisée, d'accès au support afin d'émettre les trames. Cette procédure est
communément appelée le MAC : Medium Access Control. D'une manière générale étant
donné que le support est partagé entre toutes les stations d'un réseau local, seule une trame
à la fois est véhiculée par le support. Le MAC veille donc à donner équitablement la parole à
chaque station, et bien sûr détecte les éventuelles cacophonie si certaines stations ne
respectent pas le jeu. Enfin le MAC défini le format de la trame de niveau 2. Vous pouvez
assimilé le MAC à la procédure de niveau 2 au même titre qu'HDLC par exemple pour un réseau
WAN.

Pour la suite de ce chapitre, il est important de retenir que :

• un LAN est un réseau de diffusion qui partage son support entre toutes les stations présentes
(technologie logique du bus).
• un LAN implémente une procédure de niveau 2 nommée MAC qui définie un format de trame
et gère la méthode d'accès au support.

en raison de la caractèristique de diffusion, le MAC défini un adressage de niveau 2 pour les

trames (adresse de destination et adresse source

).

Principaux LAN

La star incontestée est Ethernet ! Ce type de réseau local représente aujourd'hui plus de 80%
du parc. Il se décline en plusieurs débit, 10, 100, 1000 et bientôt 10 000 Mbps ! Les appelations
courantes sont respectivment Ethernet, Fast Ethernet, Giga Ethernet et 10 Giga Ethernet (il
y a même des bruits de couloirs sur du Tera Ethernet ! Moi ça me fait peur !).
 99

Un autre réseau local assez connu, mais en sérieuse perte de vitesse : Token Ring (Anneau à
jeton). C'est une production d'IBM ! Belle technique, bonne qualité de service mais pas assez
ouvert, trop complexe. N'existe que dans les environnement IBM d'ancienne génération
(SNA). Il se décline en deux versions 4 et 16 Mbps.

Parfois vous entendrez parler de FDDI mais pour moi c'est un MAN (Metropolitan Area
Network) offrant une couverture géographique d'une centaine de Km. Ce n'est pas un LAN.
Mais il est vrai qu'il est parfois utilisé en LAN pour son débit (100 Mbps) et sa fiabilité (double-
anneau à reconfiguration automatique). C'est une technologie assez chère.

L'adressage MAC

Ce qui nous préoccupe dans ce cours, c'est l'adressage de niveau 2. En effet sur un LAN, les
stations voient passer toutes les trames émises, il faut donc qu'elles puissent différencier
celles qui les concerne des autres. Pour cela, elles vont se baser sur l'adresse destination de
la trame. Une station ne lira le contenu que des trames qui lui sont adressées.

Quand une trame est adressée à une station unique du réseau local, elle comporte un format
d'adresse dit "unicast". Mais une trame peut également être adressée à un groupe de stations
ou à toutes les stations du réseau local. L'adressage est alors respectivement nommé
"multicast" et "broadcast".

La station qui reçoit une trame doit pouvoir y répondre. Chaque trame posséde donc une
adresse MAC source qui permet au destinataire d'identifier l'émetteur.

Pour des raisons que je ne présenterai pas ici, l'adressage MAC garanti l'unicité mondiale d'une
adresse. L'adresse d'une station est d'ailleurs inscrite "en dur" sur la carte réseau installée
dans la machine.

Cette adresse est définie sur 6 octets. Les trois premiers octets indiquent le numéro du
constructeur et les trois derniers indiquent le numéro de la carte dans la série du
constructeur. Si demain vous voulez vous mettre à produire des cartes Ethernet, pour faire
concurrence à 3Com (les fameuses EtherLink), il vous faudra d'abord demander à un
organisme central (je sais plus lequel !), une adresse constructeur. Après quoi, vous vous
engagez à ne pas produire deux cartes ayant le même numéro sur les toris derniers octets.
Ainsi l'unicité de l'adresse est garanti ! Bien sûr si vous décidez de concurrencer Cisco il vous
faudra prendre plusieurs adresses constructeurs, pour pouvoir produire toutes vos cartes !
Mais sur 6 octets c'est :

• 224 (plus de 16 millions !) constructeurs possibles

• 224 (plus de 16 millions !) cartes par constructeur !

En vérité, pour assurer les adressages multicast et broadcast, certains bits sont bloqués
notamment sur la partie constructeur ! Mais on a de la marge !

Lorsqu'on énonce une adresse MAC, on donne sa valeur en hexadécimal pour chaque octet
(Et oui ! Après le décimale et le binaire, on passe à l'héxadécimal ! Pas facile le réseau !). Par
exemple : 00.00.0C.1A.BE.34 ! Super lisible non ?
 100

Peu importe ! Retenez simplement :

• qu'une adresse MAC se définie sur 6 octets

• qu'il existe des adresses MAC destinations "unicast", et "broadcast" (vous pouvez oublier le
"multicast" pour ce cours !). L'adresse destination broadcast a pour valeur héxadécimale :
FF.FF.FF.FF.FF.FF (tous les bits à 1 !).
• que l'adresse est, généralement, fixée "en dur" sur la carte réseau de la machine. Autrement
dit, si vous changez la carte réseau d'une machine vous allez changer d'adresse MAC !! Croyez-
moi, ce n'est pas anodin si j'insiste sur ce point !

Vous n'avez pas besoin d'en savoir plus pour aborder ARP.

ROLE D'ARP
Nous avons vu qu'une station ne lisait le contenu d'une trame qu'à la condition qu'elle lui soit
adressée. Or le paquet IP est justement placé dans la trame ! Lorsqu'une couche haute
transmets des données à une autre machine, elle communique à la couche IP, l'adresse IP de
destination.

IP formate ensuite un paquet avec une entête IP. Celle-ci comportent l'adresse de destination,
transmise par la couche supérieure, et l'adresse IP source de l'émetteur. Cette dernière est
connu par IP car vous l'avez initialisée lors de l'installation de la machine.

IP communique ce paquet à la couche 2 (ici le MAC) pour l'encapsuler dans une trame MAC
avant émission sur le support. Mais il doit également communiquer l'adresse MAC de
destination de la trame, pour que la couche 2 puisse formater correctement la trame ! D'où
IP sortira-t-il cette adresse ? Il va l'inventer ? Non ... ARP est là !

ARP pour Address Resolution Protocol prend en charge, comme son nom l'indique, la
résolution d'adresse entre le niveau 2 et le niveau 3. Il a pour rôle de trouver l'adresse MAC
correspondant à une adresse IP donnée.

Lorsqu'il a découvert cette adresse, il met à jour une table ARP !

Fonctionnement d'ARP
 101

Nous venons de voir qu'IP doit transmettre à la couche MAC l'adresse de destination MAC de
la trame qui véhiculera le paquet IP transmis. La procédure est la suivante :

• IP scrute sa table ARP pour trouver la correspondance MAC de l'adresse IP transmise par la
couche supérieure :
o S'il n'a jamais communiqué avec la station ayant cette adresse depuis son "boot" (la
table ARP est en RAM, donc volatile !), il ne connaît pas la correspondance et passe à
l'étape suivante.
o S'il trouve la correspondance il transmet l'adresse MAC à la couche MAC en même
temps que son paquet IP (rappelez-vous le modèle OSI et le dialogue vertical inter-
couches !) et c'est fini pour lui !

• S'il ne trouve pas de correspondance, il transmet l'adresse IP destination au protocole ARP, en

lui demandant de trouver la correspondance d'adresse MAC :
o ARP formate un paquet ARP Request (nous verrons son format plus tard), qu'il place
directement dans une trame MAC "broadcast". Celle-ci, parce qu'elle est émise en
broadcast, est lue par toutes les stations du LAN. Le paquet ARP_Request dit : "Coucou,
je suis 10.0.0.1 sur 00.00.0C.1A.34.EC et je cherche 10.0.0.2. Y a quelqu'un ??".

o Toutes les stations actives du réseau reçoivent la trame et lisent son contenu. Elles
détectent un paquet ARP-Request qu'elles transmettent à leur propre sous-
programme ARP.
o Seule la station ayant l'adresse IP indiquée dans le paquet ARP_Request répondra !
Elle émettra un paquet ARP_Reply annonçant : "Salut 10.0.0.1 ! Moi je suis bien
10.0.0.2 et j'habite à 00.00.0C.2A.32.55 ! Ecris-moi !". Ce paquet ARP_Reply est
 102

encapsulé dans une trame émise en "unicast" à la station qui a recherchée l'adresse
(adresse MAC : 00.00.0C.1A.34.EC pour notre exemple), il est, en effet, inutile
d'embêter tous le monde avec la réponse ! La station en profite également pour
mettre à jour sa table ARP (pour notre exemple : 10.0.0.1 = 00.00.0C.1A.34.EC).

• La station ayant initié la séquence ARP, reçoit donc une trame MAC qui lui est adressée et
contenant un paquet ARP_Response véhiculant l'adresse MAC en correspondance avec
l'adresse IP sur laquelle elle a lancé la recherche. Elle met à jour sa table ARP (pour notre :
10.0.0.2 = 00.00.0C.2A.32.55).

La séquence de recherche est terminée ! Maintenant IP peut envoyer son paquet à la couche
MAC en transmettant l'adresse MAC !

Vous voyez, ARP c'est très simple !

Formats des paquets ARP

 103

ARP est encapsulé directement dans IP (il n'est pas placé dans UDP ou TCP). Il propose deux
paquets :

▪ La requête pour initier la recherche : ARP_Request

▪ La réponse à la requête : ARP_Reply
• Le champ HW : indique le type de réseau support sur lequel la séquence a été activée. Pour
Ethernet le code est (0001)h.
• Le champ Longueur d'adresse MAC : indique le nombre d'octets des champs d'adresse MAC
des paquets ARP. La valeur est généralement (0006)h.
• Le champ Longueur d'adresse protocolaire : indique la longueur en octets des champs
d'adresse de niveau 3. Pour IP la valeur est (0004)h..
• Le champ Code d'opération : indique le type de paquet ARP. (0001)h = ARP_Request et
(0002)h = ARP_Response (appelé aussi ARP_Reply).
• Les champs adresse MAC source et adresse protocolaire source : supportent les adresses
MAC et protocolaire (IP) de l'émetteur du paquet. Dans le cas d'un paquet ARP_Request ce
sont donc les adresses niveau 2 et 3 de l'initiateur de la séquence ARP. Dans le cas du paquet
ARP_Reply, la station répondant à la requête ARP y place ses propres adresses niveau 2 et 3.
• Les champs adresse MAC destination et adresse protocolaire destination : supportent les
adresses MAC et protocolaire (IP) de la station à atteindre. Dans le cas d'un paquet
ARP_Request ce sont donc les adresses niveau 2 et 3 de la station pour laquelle l'initiateur de
la séquence ARP a lancé la recherche. Comme l'émetteur du paquet ne connait pas l'adresse
niveau 2 de la station qu'il cherche à atteindre (normal ! c'est justement ce qu'il cherche à
connaître !), le champ adresse MAC destination est placé à 0. Dans un paquet ARP_Request le
champ adresse MAC destination est donc toujours à 0, par contre le champ adresse
protocolaire destination contient toujours l'adresse niveau 3 de la station dont on veut faire la
résolution d'adresse. Dans le cas du paquet ARP_Reply, la station répondant à la requête ARP
remplace les valeurs de ces champs par les valeurs d'adresse de l'émetteur du paquet
ARP_Request. Elle recopie en fait les champs adresse MAC source et adresse protocolaire
source du paquet ARP_Request reçu dans les champs destination correspondants du paquet
ARP_Reply émis en réponse.

Quelques remarques à propos d'ARP

Les problème liés à la table ARP

Je vous l'ai précédemment indiqué la table ARP est mémorisée en RAM. De plus, dans la
majorité des cas il n'y a pas de timeout sur les tables ARP. Ceci veut dire que lorsqu'une
correspondance MAC-IP a été réalisée elle reste mémorisée dans la station jusqu'au "reboot"
de celle-ci. Et croyez-moi ! Ce n'est pas anodin !

Dans une architecture classique des stations et des serveurs partageant le même réseau local
discutent ensemble. Supposons qu'un PC rencontre un problème vous allez le remplacer. La
carte réseau du nouveau PC aura une adresse MAC différente. Par contre vous aurez réaffecté
au PC la même adresse IP. Mais le serveur a mémorisé dans sa table ARP la correspondance
"Ancienne @MAC-@IP". S'il émet des données vers le PC celui-ci ne lira pas les trames puisque
leurs adresses destinations ne correspondent pas à son adresse MAC !

Rassurez-vous ! Pour un PC ce n'est pas grave ! En effet, pour le remplacer vous avez dû le
mettre hors tension. Le nouveau PC a donc une table ARP vierge. Comme un PC est plutôt
 104

client, c'est lui qui va demander des infos au serveur, ce n'est pas le serveur qui va décider de
lui parler de lui-même (il a autre chose à faire, le bougre, que de faire la causette aux nouveaux
qui lui demandent rien !!). Le PC va donc lancer une séquence ARP vers le serveur pour mettre
à jour sa table et le serveur va en profiter pour détecter la modification d'adresse MAC et
mettre à jour sa propre table !

Mais imaginons que vous remplaciez une station qui ne cause pas toute seule sans être
sollicitée ! Imaginez que vous remplaciez un serveur ou un routeur !! Pensez-bien à faire
rebooter les PC du LAN ... Sinon ... Plus de communication avec le serveur ou le routeur !
Toutes les tables ARP des stations sont fausses pour la résolution d'adresse de l'équipement
que vous avez remplacé !

ARP et la passerelle par défaut

Dans les exemples de routage des chapitres précédents, et notamment dans le paragraphe
"Sortir du réseau" du chapitre 6, nous avons vu qu'une station envoie son paquet à une
passerelle par défaut lorsque le paquet est à destination d'un autre réseau IP.

Nous avons très succintement évoqué le rôle d'ARP dans ce mécanisme. En effet, comment
envoyer un paquet IP à destination de 12.0.0.1 en voulant le tranférer à 10.0.0.254 sans
changer l'adresse IP du paquet ? C'est simple ... On l'envoie dans une trame ayant pour adresse
destination, l'adresse MAC du routeur (passerelle).

Lorsque la station doit envoyer un paquet en dehors de son réseau IP, elle scrute sa
configuration pour trouver l'adresse de Gateway Default que vous lui avez donné lors de son
installation. Puis elle regarde dans sa table ARP, l'adresse MAC correspondante à l'adresse IP
de la Gateway Default. Si celle-ci existe dans la table ARP, la station encapsule son paquet IP
dans une trame à destination de l'adresse MAC de la passerelle. Si celle-ci n'existe pas, elle
lance une procédure de résolution d'adresse ARP, telle que nous l'avons précédemment
étudié !

Et le tour est joué ! La passerelle reçoit une trame qui lui est destinée et qui véhicule un paquet
IP qui ne lui est pas destiné. Elle applique l'organigramme de routage tel que nous l'avons vu
au chapitre 6.

La tempête du matin ...

Tous le monde commence son travail entre 8 et 9 heures le matin ... Enfin c'est la moyenne
des bureaux ... En arrivant la première opération est d'allumer son PC avant même de retirer
son manteau (on espère que Windows aura fini son boot quand on sera revenu du premier café
!).

Comme les tables ARP sont vides à ce moment là (rappelez-vous, elles sont stockées en RAM,
donc volatile). Dès qu'on va appelé un serveur il va falloir renseigner la table ARP. Chaque fois
qu'on appelle une ressource il faut de nouveau renseigner cette table.

Les requêtes sont véhiculées par des trames "broadcast", qui sont donc luent par toutes les
stations. Bien souvent seuls les serveurs sont sollicités et sont donc les seuls à répondre.
 105

Quoiqu'il en soit, lorsque vous placez un analyseur sur un réseau LAN vous assistez à des
"tempêtes de broadcast" dans ce créneau horaire. Ceci entraîne une surcharge momentanée
du réseau ... Il est déconseillé de procéder dans ce créneau horaire à des opérations lourdes
de duplication de bases par exemple !! Vous noterez un ralentissement non négligeable !

Les serveurs doivent répondre à des centaines de requêtes ARP, le LAN véhicule deux trames
par requête, toutes les stations lisent les broadcast des requêtes ARP ... Et on travaille quand
?

ARP et la sécurité !

ARP est un bonheur pour les "hackers" et une plaie pour les administrateurs. En effet grâce à
ARP, si vous avez les moyens d'accèder au LAN, vous pouvez connaître très rapidement
l'ensemble des stations présentent sur un LAN !

Avec un peu de connaissance, vous pouvez programmer un petit utilitaire ou installer sur votre
PC un analyseur qui va scruter le contenu de tous les ARP_Request et ARP_Reply émis sur le
LAN. Vous aurez ainsi découvert toutes les adresses niveau 2 et 3 des équipements du LAN.

Ne reste plus qu'à faire "sauter" les protections des couches supérieures ...

Vous pouvez même vous substituer à une station lorsque celle-ci aura réalisé son
authentification d'accès auprès d'un serveur !! Vous attendez qu'elle entre son
login/password en surveillant le trafic. Puis vous reprogrammez votre station avec l'@MAC et
l'@IP de la station. Vous accédez ainsi en son nom au serveur, et lui ni voit que du feu !

Vous allez me dire qu'il faut quand même accéder au LAN ! Certes, mais les anglo-saxons
estiment que 70% des actes de piratages ont pour source l'intérieur de l'entreprise. Je vous
accorde qu'ils sont un peu parano, mais ...

Rassurez-vous, des mécanismes de couches supérieures permettent de vaincre ce trou de

sécurité, mais il existe aussi des moyens de les faires sauter !

Le proxy-ARP, c'est quoi ?

Vous avez peut-être déjà croisé ce terme en vous demandant pourquoi un ARP de proximité
? En fait c'est un ARP qui trompe !!

Supposons que votre entreprise rachète une autre entreprise (disons que vous travaillez chez
Cisco, Intel ou Microsoft !). Le siège de cette nouvelle entreprise posséde un réseau local
supportant l'adresse réseau 10.0.0.0. Pas de chance ! C'est la même adresse réseau que celle
de votre siège ! Et bien sûr, votre PDG veut que vous interconnectiez les deux sites (heu ..
Plutôt DSI ! Un PDG, ne sait pas ce que veut dire "interconnecter" ! Lui il dit : "Fusionner moi
nos bases de connaissances !").
 106

Vous voilà bien embêté ! Si vous placez un routeur entre les deux, il va être malade si vous
placez chacune de ces interfaces dans le même réseau IP (croyez-moi, il ne se laissera pas faire
! Belliqueux l'engin !).

Mais dans votre malheur, vous avez un peu de chance (croyez-moi, profitez-en ! Parce que
c'est pas souvent !). En effet, en examinant le plan d'adressage de l'entreprise achetée vous
remarquez que tous les équipements de son réseau local ont pour adresses 10.1.X.X avec un
masque 255.0.0.0. Or vos stations sont toutes avec une adresse 10.2.X.X/8 ! Quelle chance
(croyez-moi ! J'insiste ! C'est pas souvent !) ! Vous allez vous en sortir avec Proxy-ARP, sans
être obligé de reprogrammer toutes les stations (ben oui .. Vous connaissez pas DHCP alors
vous en êtes pour vos frais .. C'était une petite remarque à l'attention des experts dans le fond
de la salle, qui sont tordus de rire !).

Vous avez remarqué que les stations avaient un masque de réseau classe A sans sous-réseau.
Autrement dit, la station 10.2.0.1 de votre siège estime que le serveur 10.1.0.1 du siège de
l'entreprise achetée est sur son réseau IP ! Elle va donc tenter de le contacter directement
sans passer par votre routeur installé entre les deux réseaux ! Quand elle lancera une requête
ARP pour connaître l'adresse MAC du serveur, elle n'obtiendra rien puisqu'il n'est pas sur son
LAN !

En installant un routeur entre les deux réseaux, qui implémente la fonction Proxy-ARP vous
allez résoudre le problème ! Vous devez simplement placer chaque interface du routeur dans
un sous-réseau différent :

• L'interface branchée sur le LAN de l'entreprise achetée sera paramétrée avec l'adresse
10.1.254.254/16 (le masque indique que l'interface est dans le sous-réseau 10.1.0.0).
• L'interface branchée sur le LAN de votre siège sera paramétrée avec l'adresse 10.2.254.254/16
(le masque indique que l'interface est dans le sous-réseau 10.2.0.0).

Si la fonction Proxy-ARP est implémentée dans le routeur, voici ce qui va se passer :

 107

• 10.2.0.1 va tenter de trouver l'adresse MAC de 10.1.0.1 par un ARP_Request. Cette requête
est émise dans une trame MAC en broadcast (Flèche 1 sur le schéma) . Toutes les stations du
réseau vont lire cette trame !
• Le routeur, qui est une station comme les autres, va lire la trame, transférer le paquet ARP à
son module ARP ! Il verra que ce n'est pas son adresse IP d'interface qu'on sollicite.
• Mais, si le Proxy-ARP est actif, il va essayer de corréler l'adresse réseau recherchée avec celles
existants dans sa table de routage. Il va donc voir qu'on cherche à joindre une station du sous-
réseau 10.1.0.0 qui est sur son autre interface ! Il va alors se substituer à l'adresse demandée,
en répondant à l'ARP_Request, par un ARP_Response (Flèche 2 du schéma) donnant l'adresse
MAC de son interface sur le LAN 10.2.0.0.
• La station va croire que c'est 10.1.0.1 qui lui répond et va initialiser dans sa table ARP, la
correspondance 10.1.0.1 = @MAC routeur. Tous les prochains paquets émis à 10.1.0.1 seront
donc placés dans des trames à destination du routeur !

Et c'est très bien comme ça ! Le routeur pourra router les paquets et tout le monde sera
content !

C'est ça le Proxy-ARP !!

Conclusion du chapitre
Ouf ! C'en est fini d'ARP ! Pas compliqué, mais difficile à expliquer par écrit !! Pas trop fatiguant
ce chapitre ? Normal ! On prenait des forces pour la suite ...

Dans le chapitre suivant (pour se réveiller) on va fragmenter le paquet IP ! C'est sympa un

paquet IP en petits morceaux, non ?
 108

CHAPITRE 10 : FRAGMENTATION IP

La fragmentation des paquets IP

Introduction
Arrivé à ce stade du cours, vous commencez à être très instruits ! Vous savez :

• qu'IP est un protocole de niveau 3 qui est donc encapsulé dans un protocole de niveau 2 (voir
le chapitre 4 du modèle OSI)
• qu'IP est conçu pour fonctionner sur divers types de réseaux physiques (Liaisons Louées,
Réseaux locaux Ethernet, Token Ring, FDDI voir même liaisons satellites)
• que chaque réseau physique implémente un protocole de niveau 2 qui lui est propre (MAC
Ethernet, MAC Token Ring, HDLC pour les liaisons louées, etc.). Si vous n'en êtes plus
convaincu, rendez vous aux chapitre 4 et chapitre 7 du cours sur le modèle OSI.

Que se passe-t-il quand un paquet IP est routé à travers plusieurs réseaux de types différents
? Il est encapsulé dans diverses couches de niveaux 2 successives. Mais ces couches peuvent
mettre en oeuvre des protocoles de niveau 2 différents, si les réseaux physiques sont
différents. Par exemple, en passant d'un LAN Ethernet à un LAN Token Ring vous changez de
protocole de niveau 2. L'un utilise le MAC Ethernet et l'autre le MAC Token Ring, qui sont
totalement différents.

Si ces protocoles sont différents, leurs caractéristiques le sont également (la palisse !). Une
des caractéristiques qui risque fort de différer et qui nous intéresse ici est la taille de la MTU
!

Qu'est-ce donc encore que ce truc ? La MTU, pour Maximum Transmission Unit est la taille du
champ information de la trame. C'est à dire la taille du champ où l'on va placer le paquet IP !
Vous voyez où je veux en venir ?

Si au cours du transfert du paquet IP une passerelle doit le réencapsuler dans une trame ayant
un champ information plus petit que la taille du paquet IP, elle va devoir sortir la presse ou la
tronçonneuse !

IP n'a pas choisi la presse, il préfére la tronçonneuse ! Mais rassurez-vous, il est respectueux
de vos paquets de données chéris ! Il fait ça bien, sans effusions de sang inutiles ! C'est propre,
net et sans cicatrice !

IP a donc prévu un mécanisme de fragmentation qui lui permet de découper un paquet en

plusieurs fragments, puis lui permet de reconstituer le paquet original à l'arrivée !
 109

IP : un protocole en mode non connecté !

Mais avant d'étudier la méthode de fragmentation, il faut se rappeler un point important : IP
est un protocole de niveau 3 en mode non connecté. Je vous invite à réviser cette notion dans
le chapitre 8 du cours OSI.

Un protocole non connecté, comme son nom l'indique, n'établi pas de connexion avec son
correspondant avant d'entamer un transfert de données. Le chemin parcouru par les données
dans le réseau n'est donc pas préalablement fixé ! Pire ! Ce chemin peut varier d'un paquet à
l'autre !

A chaque chemin correspond un délai d'acheminement qui lui est propre. Celui-ci est fonction
du nombre de passerelles à traverser, des débits et de la charge des liaisons, des délais de
transit sur ces liaisons (surtout sensible dans le cas des liaisons satellites 2*36 000 Km = 72 000
Km de long. Vous savez que l'altitude d'un satellite géo-stationnaire est de 36 000 Km n'est ce
pas ?).
 110

En conséquence, il est possible qu'un paquet IP émis après un autre, arrive à destination avant
l'autre (je vous accorde que ce n'est pas souvent, mais ça peut arriver !).

On dit qu'en mode non connecté le séquencement des paquets en réception n'est pas garanti
identique au séquencement des paquets à l'émission. En vérité, comme on aime pas les
phrases longues on dit : il n'y a pas de garantie du séquencement ! (c'est plus court non ?).

Retenez-bien cette contrainte ! Parce que dans le cas de la fragmentation, c'est loin de nous
simplifier la vie !

Fragmentation et en-tête IP
Rappelez-vous le format du paquet IP (je sais ... C'est loin déjà !). Les octets 5 à 8 de l'entête
se nomment Identificateur, Flag et Fragment Offset. Nous avions dit que ces octets étaient
réservés à la fragmentation (ou segmentation, comme vous voulez !).

Expliquons un peu mieux à quoi servent ces octets :

• le champ Identificateur (2 octets) : c'est un numéro d'identification inscrit par l'émetteur du

paquet. Tous paquets émis par une même machine à l'attention d'un même destinataire porte
un numéro d'identification différent. En cas de fragmentation, ce numéro d'identification est
recopié dans tous les fragments du paquet d'origine. Ceci permettra au destinataire de repérer
tous les fragments d'un même paquet et de reconstituer le paquet d'origine.
• le champ Flag (3 bits) : il permet de gérer la fragmentation :
o bit 0: réservé - toujours positionné à 0
o bit 1 : dit bit DF (Don't Fragment) - S'il est positionné à 0, la fragmentation est autorisée
- S'il est positionné à 1 la fragmentation est interdite. Dans ce dernier cas, si le paquet
est trop volumineux pour être encapsulé dans une trame, dont le MTU est inférieur à
la taille du paquet, la passerelle qui devrait réaliser la fragmentation retournera à
l'émetteur du paquet un ICMP "Paquet non fragmentable".
 111

obit 2 : dit bit MF (More Fragment) - S'il est positionné à 0 il indique que le paquet reçu
est le dernier du paquet d'origine. S'il est positionné à 1, il indique que le paquet reçu
est un fragment du paquet d'origine mais pas le dernier fragment. Un paquet qui n'a
pas été fragmenté aura donc toujours ce bit à 0.
• le champ Fragment Offset : indique la position du premier octet de données du paquet reçu
dans la partie donnée du paquet d'origine. Le premier fragment à donc toujours la valeur 0
(position du premier octet), de même que tous paquets non fragmentés.

Cela vous paraît un peu nébuleux ? Pas clair ? La démonstration par l'exemple sera sans doute
plus efficace !

Comment ça marche ?
ATTENTION !

Un lecteur averti et studieux m'a signalé une erreur importante ci-dessous. L'offset est calculé
en mot de 20 octets et non pas à l'octet prêt ! En conséquence l'exemple ci-dessous est correct
dans sa logique mais faux dans ses valeurs d'offset.

Je n'ai pas encore eu le temps de réécrire ce paragraphe, mais merci d'en tenir compte !

Supposons que deux stations, A et B, émettent des paquets vers un serveur S. Les paquets
transitent à travers un réseau dans lequel il est nécessaire de fragmenter les paquets d'origine
qui sont trop volumineux pour passer sur un des supports du réseau. Imaginons que les
paquets de départs ont une taille de 4024 octets (4000 octets de données et 24 octets d'entête
IP). Dans le réseau une MTU d'un support est limitée à 1024 octets !

La station A émet deux paquets à la suite pour S et la station B n'en émet qu'un ! Enfin, pour
faire simple, après l'endroit de fragmentation dans le réseau, le séquencement des paquets
n'est pas respecté suite à une reconfiguration automatique du routage. Cela a eu pour effet
d'envoyer les premiers paquets sur une route chargée alors que les paquets suivants ont
emprunté une route non chargée. En conséquence les paquets arrivent dans le désordre au
serveur !

Question : Combien de fragment vont être généré par paquet de 4 000 octets émis ?

Réponse : Chaque fragment ne peut dépasser 1024 octets dont 24 octets d'en-tête, il
véhiculera donc 1 000 octets utiles. Comme le paquet d'origine fait 4024 octets dont 24 octets
d'entête, il a 4 000 octets utiles. Il faut donc 4000/1000 fragments soit 4 fragments par paquet
de 4024 octets. Comme il y a trois paquets émis au total par A et B, le serveur recevra 12
paquets !

Emission de A :

A envoie son premier paquet PA1 vers S. Ce paquet fait 4024 octets, à l'adresse IP source
@IPA et l'adresse destination @IPS du serveur. Le paquet n'est pas fragmenté, c'est le paquet
originel donc MF(PA1) = 0 et Offset(PA1) = 0. Un numéro d'identification est fixé ID(PA1) =
1000. La fragmentation est autorisée donc DF(PA1) = 0.
 112

Puis immédiatement à la suite A envoie son deuxième paquet PA2 vers S. Ce paquet fait 4024
octets, à l'adresse IP source @IPA et l'adresse destination @IPS du serveur. Le paquet n'est
pas fragmenté, c'est le paquet originel donc MF(PA2) = 0 et Offset(PA2) = 0. Le numéro
d'identification est incrémenté car c'est le deuxième paquet à destination de S, il est fixé à
ID(PA2) = 1001. La fragmentation est autorisée donc DF(PA2) = 0.

Emission de B :

Juste après que A est envoyé son premier paquet, et avant que A n'envoie son deuxième
paquet, B émet son propre paquet. Elle émet PB1 vers S. Ce paquet fait 4024 octets, à
l'adresse IP source @IPB et l'adresse destination @IPS du serveur. Le paquet n'est pas
fragmenté, c'est le paquet originel donc MF(PB1) = 0 et Offset(PB1) = 0. Un numéro
d'identification est fixé ID(PB1) = 1000 (Je fais exprès de prendre le même que A, bien que les
chances que cela se produise sont très faibles, pour vous montrer que c'est pas grave !). La
fragmentation est autorisée donc DF(PB1) = 0.

Dans le réseau une passerelle reçoit les paquets dans l'ordre PA1, PB1, PA2, elle doit les
fragmenter :

Fragmentation de PA1 :

o La passerelle tronçonne la partie Data du paquet reçu en 4 paquets de 1000 octets

(dingue ça ! Ca tombre juste ! Trop fort !).
o Puis elle envoie le premier fragment F1PA1 avec adresse source @IPA et adresse
destination @IPS. Le bit DF(F1PA1) = 0, il est toujours recopié à sa valeur d'origine. Le
bit MF(F1PA1) = 1, car le premier fragment n'est pas le dernier (sans blague ?) du
paquet d'origine. Elle recopie la valeur de l'ID du paquet d'origine soit ID(F1PA1) =
1000. Puis elle positionne à 0 l'offset car c'est bien la position du premier octet de
données du fragment dans le paquet d'origine, Offset(F1PA1) = 0.
o La passerelle émet ensuite le deuxième fragment F2PA1 avec les mêmes
caractéristiques que le premier fragment F1PA1, sauf l'ID(F2PA1) égal à l'ID(F1PA1) +
nombre d'octets utiles véhiculés par F1PA1. Soit ID(F2PA1) = ID(F1PA1) + 1000 = 0 +
1000 = 1000.
o La passerelle émet le troisième fragment sur les même caractéristiques que les deux
premiers avec seulement l'ID(F3PA1) qui différe. ID(F3PA1) = 2000 (ID(F2PA1) + 1000).
o Enfin elle émet le dernier fragment F4PA1 du paquet PA1. Celui est également
identique aux précédents hormis : l'ID(F4PA1) = 3000 (ID(F3PA1) + 1000) et le bit
MF(F4PA1) = 0. En effet F4PA1 est le dernier fragment du paquet d'origine, le bit MF
est donc positionné à 0.

Fragmentation de PA2, le principe est le même que pour PA1 :

o F1PA2 : IPsource = @IPA - IPdest. = @IPS - DF = 0 - MF = 1 - ID = 1001 - Offset = 0

o F2PA2 : IPsource = @IPA - IPdest. = @IPS - DF = 0 - MF = 1 - ID = 1001 - Offset = 1000
o F3PA2 : IPsource = @IPA - IPdest. = @IPS - DF = 0 - MF = 1 - ID = 1001 - Offset = 2000
o F4PA2 : IPsource = @IPA - IPdest. = @IPS - DF = 0 - MF = 0 - ID = 1001 - Offset = 3000

Fragmentation de PB1, c'est le même mécanisme ! Je vous laisse faire ?

 113

Il y a donc 12 fragments émis par la passerelle vers le serveur S. Sur le chemin, entre la
passerelle et le serveur, une reconfiguration dynamique du routage a lieu après le passage de
F1PA1 à F2PA2. Les fragments F3PA2 a F3PB1 sont émis sur une route différente, plus rapide.
Le serveur reçoit donc dans l'ordre : F3PA2, F4PA2, F1PB1 à F4PB1 puis F1PA1 à F2PA2. Le
quarté dans le désordre !

Réassemblage des paquets par le serveur :

Toute machine IP maintien des buffers mémoire dans lesquels elle stocke les paquets en
attente de réassemblage. La zone mémoire allouée a une taille définie par la taille du paquet.
Cette taille varie en fonction des fragments qui arrivent au fil de l'eau. Le début de la zone est
marqué par le premier fragment, la fin de zone par le dernier fragment. Il y a une zone
mémoire par couple ID-@SourceIP.

IMPORTANT : La méthode de gestion de l'allocation mémoire présentée ici est une

supposition. Il n'existe, à ma connaissance, pas de description normalisée de ces opérations.
En conséquence cette méthode peut différer d'une implémentation IP à une autre. Quelle
qu'elle soit précisément, le principe est bien de stocker les fragments en tampon, jusqu'à
reconstitution compléte du paquet originel.

Logique appliquée :

Lorsque le serveur reçoit un paquet, il examine l'adresse source (on suppose que l'adresse
destination a déjà été validée), l'ID, l'offset et le bit MF :

• si MF = 0 et Offset = 0 : ce n'est pas un fragment, c'est un paquet originel. Le serveur place ce

paquet sur la file d'attente du protocole supérieur véhiculé par le paquet. Ce protocole est
indiqué dans le champ Protocole de l'entête IP.
• si MF = 0 et Offset <> 0, le paquet est le dernier fragment d'un paquet originel. Le serveur
examine le couple ID-@SourceIP du fragment :
o s'il a déjà en buffer une zone mémoire pour ce couple, il place le paquet en fin de file
de buffer.
o s'il n'a pas de couple ID-@IPsource identique en buffer, il crée une zone mémoire en
buffer et place le paquet en fin de file.
• si MF = 1 et Offset = 0, le paquet est le premier fragment d'un paquet originel. Le serveur
examine le couple ID-@SourceIP :
o s'il a déjà en buffer une zone mémoire pour ce couple, il place le paquet en début de
file de buffer.
o s'il n'a pas de couple ID-@IPsource identique en buffer, il crée une zone mémoire en
buffer et place le paquet en début de file.
• si MF = 1 et Offset <> 0, le paquet est un des fragments d'un paquet originel. Le serveur
examine le couple ID-@SourceIP du fragment :
o s'il a déjà en buffer une zone mémoire pour ce couple, il place le paquet à l'offset
indiqué dans le buffer, en décalant éventuellement la zone mémoire des fragments
suivants déjà en place.
o s'il n'a pas de couple ID-@IPsource identique en buffer, il crée une zone mémoire en
buffer. Cette zone a la taille de la valeur d'offset + la taille du fragment.
 114

Le serveur considére la file d'attente compléte quand il a placé le premier et le dernier

fragment ainsi que tous les fragments intermédiaires (vérification de la valeur d'offset +
longueur de chaque fragment). Il remonte alors la partie Data au protocole identifié par le
champ Protocole de l'entête IP du paquet originel reconstitué.

Séquencement de reconstitution des paquets de A et B :

• Réception de F3PA2 : MF = 1 - ID = 1001 - IPsource = IPA - Offset = 2000 :

o Zone mémoire 1001-IPA inexistante -> Création d'une zone de 2000 + 1000 + 24 octets
(entête IP) = 3024 octets.
o Recopie de l'entête IP de F3PA2 sur les 24 premiers octets en plaçant DF, MF et Offset
à 0. Les autres champs gardent leur valeur.
o Placement des données de F3PA2 à l'offset 2000.
• Réception de F4PA2 : MF = 0 - ID = 1001 - IPsource = IPA - Offset = 3000 :
o Zone mémoire 1001-IPA existante -> Extension de la zone mémoire de 1000 octets à
partir de l'offset 3000.
o Placement des données de F4PA2 à l'offset 3000.
• Réception de F1PB1 : MF = 1 - ID = 1000 - IPsource = IPB - Offset = 0 :
o Zone mémoire 1000-IPB inexistante -> Création d'une zone de 1000 + 24 octets (entête
IP) = 1024 octets.
o Recopie de l'entête IP de F1PB1 sur les 24 premiers octets en plaçant DF, MF et Offset
à 0. Les autres champs gardent leur valeur.
o Placement des données de F1PB1 à l'offset 0.
• Réception de F2PB1, F3PB1 : Je vous laisse faire !
• Réception de F4PB1 : MF = 0 - ID = 1000 - IPsource = IPB - Offset = 3000 :
o Zone mémoire 1000-IPB existante -> Extension de la zone mémoire de 1000 octets à
partir de l'offset 3000.
o Placement des données de F4PB1 à l'offset 3000.
o Le paquet est complétement reconstitué -> File d'attente du protocole de couche
supérieure.
• Réception de F1PA1 à F4PA1 : Je vous laisse faire, vous savez comment cela se passe
maintenant !
• Réception de F1PA2 : MF = 1 - ID = 1001 - IPsource = IPA - Offset = 0 :
o Zone mémoire 1001-IPA existante -> Placement des données de F1PA2 à l'offset 0. La
zone mémoire avait été dimensionné correstement par l'arrivée de F3PA2. Il n'est pas
nécessaire de l'étendre.
• Réception de F2PA2 : Vous êtes grand maintenant ... Je vous laisse faire !

Voilà ! Tous les paquets ont été reconstitués par le serveur ! Vous avez pu remarquer que
c'était du travail n'est-ce-pas ? Pendant que le serveur gére ces files il ne fait pas vraiment ce
pour quoi il est payé (pas cher, c'est vrai !).

Trois remarques sur la fragmentation

Si on peut l'éviter, tant mieux !

Il est évident qu'il était impératif d'inclure un mécanisme de fragmentation dans le protocole
IP, notamment en raison du fait qu'il peut être véhiculé dans différents protocoles de couche
2, ne présentant pas toujours les mêmes MTU. Cependant si on peut éviter de fragmenter
c'est préférable. En effet :
 115

• les passerelles assurant la fragmentation doivent gérer les modifications d'entête (DF, MF,
ID, Offset, etc.) ce qui mobilise du temps CPU qu'elles ne passent pas à commuter !
• les stations destinataires sont obligés de gérer le réassemblage des paquets ce qui mobilise
du temps CPU et de la mémoire.
• si vous perdez un fragment (voir le cas du TTL ci-dessous par exemple), tout le paquet IP
originel est perdu parce qu'il n'aura pas pu être reconstitué complétement. Par contre les
ressources réseaux et machines auront été utilisées pour acheminer les autres fragments à
bon port.
• enfin, et là je vous demande me croire sur parole, on peut démontrer que dans le cas de
l'emploi d'une couche 4 TCP, la fragmentation IP diminue nettement le rendement du
protocole (sous-emploi du fenêtrage). Au point, que certaines implémentations de TCP
procéde à un test avant l'émission de leurs segments vers le destinataire. TCP recherche la
MTU minimum de la route et adapte la taille de ses messages en conséquence.

Toutes ses raisons expliquent que l'on utilise très rarement, pour ne pas dire jamais, la taille
maximum du paquet IP. La majorité des stacks IP proposent des tailles standards comprises
en 128 et 512, voir 1024 octets. La fragmentation est ainsi plus rarement employée et les
buffers des stations sont moins sollicités.

L'influence du TTL

Au chapitre 3, dans la description de l'entête IP, nous avons présenté le champ TTL (Time To
Live). Ce champ, défini sur un octet, permet d'indiquer une durée de vie au datagramme émis.

En effet, le mode non connecté, sans contrôle du séquencement, ni reprise sur erreur du
protocole IP, induit qu'un paquet peut être supprimé sans avertir qui que ce soit. Les
principes de routage dynamique peuvent également conduire à générer des boucles
(momentanément, rassurez-vous !) dans le réseau. Pour éviter qu'un paquet tourne
indéfiniment dans le réseau ou soit conservé en file d'attente indéfiniment, on lui donne une
durée de vie par le champ TTL.

A l'émission le TTL est généralement fixé à sa valeur maximum, soit 255.

Chaque fois que le paquet va traverser une passerelle, celle-ci décrémente le TTL de 1. Donc
en théorie un paquet IP ne pourra jamais traverser plus de 255 routeurs ! C'est déjà bien
suffisant ! Mais s'il était nécessaire de dépasser cette limite on pourrait utiliser une astuce
nommée : tunneling (mais ne nous éloignons pas du sujet ! Je peux pas tout vous dire ! Il faut
laisser un peu de travail à d'autres !).

Lorsqu'une passerelle passe le TTL à 0, elle détruit le paquet et éventuellement envoie un

paquet ICMP Time Exceded à l'émetteur du paquet pour l'informer de sa destruction.

Lorsqu'une passerelle fragmente un paquet, tous les fragments partent avec la valeur du TTL
d'arrivée (paquet originel) moins 1 !

Que se passe-t-il si une station de destination reçoit 3 fragments sur 4 ? Si le dernier fragment
n'arrive jamais ? La station conserve-t-elle indéfiniment les 3 fragments reçus en zone
mémoire tampon ? Vous imaginez bien que non !! Si cela se produit trop fréquemment, elle
risque de saturer ses buffers !
 116

C'est pourquoi la station va continuer de décrémenter le TTL de l'entête qu'elle a stocké en

début de zone mémoire. Cette entête est celle du premier fragment reçu, donc le plus ancien
en mémoire. Toutes les secondes elle décrémente ce TTL. S'il atteint la valeur 0 avant que
l'ensemble du paquet originel ait été reconstitué, l'ensemble de la file mémoire est effacée !

La station pourra également retourner un ICMP Time Exceded à l'émetteur pour l'informer de
la destruction de son paquet !

Bien sûr, si le dernier fragment arrive après la destruction de sa file (à la bourre le fragment
!), il sera stocké, comme précédemment dans une nouvelle file, en attente des autres
fragments, qui n'arriveront jamais puisqu'ils ont été détruit ! Mais à expiration de son TTL, il
sera également détruit !

REMARQUE : Le principe de décrémentation du TTL toutes les secondes est également

appliquée dans les files d'attentes des passerelles. Tant qu'un paquet IP reste en mémoire
(surcharge du lien de sortie, surcharge CPU, ou autres), son TTL est décrémenté. Cependant si
vous avez souvent des paquets qui restent bloqués plus d'une seconde dans votre routeur, je
vous conseille de revoir le dimensionnement de votre réseau ! Une seconde de transfert dans
une passerelle est un délai intolérable ! Les moyennes acceptées sont plutôt de 2 milli-
secondes !

Pourquoi est-ce toujours la station de destination qui réassemble ?

Tout au long de ce chapitre nous avons constamment évoqué les opérations de réassemblage
du paquet originel sur la station de destination du paquet. On aurait pu penser que le
réassemblage aurait été effectué par un équipement plus proche de la passerelle qui a réalisé
la fragmentation, par exemple son voisin direct ! Pourquoi n'est-ce jamais le cas ?

Il y a deux bonnes raisons à cela :

• la première vraie, bonne raison, est que vous ne pouvez pas garantir qu'une autre passerelle
du réseau verra passer tous les fragments d'un paquet ! Dans notre exemple précédent,
supposons qu'une passerelle placée sur la route empruntée par F1PA1 à F2PA2, après la
passerelle ayant réalisée la fragmentation, tente de reconstituer les paquets car sa MTU de
sortie permet d'accueillir des paquets plus gros :
o Elle pourra reconstituer le paquet PA1, puisqu'elle voit passer F1PA1 à F4PA1.
o Mais elle ne pourra pas reconstituer PA2 puisqu'elle ne voit passer que F1PA2 et
F2PA2, les autres fragments empruntant une autre route !
o De plus comment peut-elle connaître la taille du paquet originel, pour être en mesure
d'affirmer que son lien de sortie à une MTU suffisante au transfert du paquet originel
sans le fragmenter ? Elle devrait attendre tous les fragments, pour connaître la taille
du paquet global, et finalement se rendre compte qu'elle va devoir le fragmenter !
• la deuxième raison est que même si une MTU de sortie peut prendre en charge des plus gros
paquets, la passerelle ne connaît pas la taille des MTU des autres supports qui constituent
le reste de la route ! Elle risque de passer du temps, de consommer des ressources pour
réassembler un paquet, qui sera peut-être de nouveau fragmenté par la prochaine passerelle
!! Pas vraiment rentable tout ça !

Conclusion du chapitre
 117

Nous en resterons là, pour le chapitre de la fragmentation. Il y a encore sans doute beaucoup
à dire, mais nous avons évoqué, je pense, l'essentiel !

Nous avons jusqu'ici décrit les mécanismes majeurs du protocole IP :

• l'adressage
• le routage de base
• l'interaction avec le niveau 2 des LAN
• la fragmentation

Dans aucun des chapitres nous n'avons évoqué de contrôle d'erreur (hormis le checksum sur
l'entête) ou de reprise sur erreur. Nous savons également qu'IP fonctionne en mode non
connecté. En fait IP est un protocole de niveau 3 dit non fiable ou aussi appelé "best effort".
Il fait du mieux qu'il peut, mais il peut peu !

Nous avons évoqué les pertes de paquets mais pas de récupération ! Enfin souvent lorsque
des erreurs survenaient nous évoquions ICMP mais pas IP !

CHAPITRE 11 : ICMP : C'EST QUOI ?

LE PROTOCOLE ICMP

INTRODUCTION
Nous avons pu remarquer dans les chapitres précédents qu'IP était essentiellement accès sur
les fonctions d'adressage et de routage. Il est configuré pour fonctionner comme si aucun
problème ne pouvait survenir sur le réseau (perte de datagrammes, congestion, problème de
routage, etc.). Si un problème survient, sa solution est expéditive : il ne route pas ! Il a tout
juste accepté de prendre en charge les problèmes de fragmentation !

Ce mode de fonctionnement n'est pas un problème en soi (il suffit de regarder la notoriété et
l'implantation d'IP !). Mais il est nécessaire de pouvoir dans certains cas informer les
émetteurs du devenir de leurs datagrammes.

C'est le rôle d'ICMP (Internet Control Message Protocol) qui, comme son nom l'indique, est
un protocole d'information du contrôle de réseau. ICMP ne résoud rien, ou du moins pas
grand chose, il informe ! Lorsque certains problèmes de routage se présentent, il émet un
message d'information à l'émetteur du datagramme en péril !

Dans 80% des cas, l'émetteur s'en fiche ! Triste monde ...

Ce n'est pas tout à fait vrai ... La couche IP de l'émetteur s'en fiche ! Mais l'information pourra
éventuellement (cela dépend des développements) exploiter ces infos !

ICMP, véhiculé dans IP

 118

Du point de vue d'IP, ICMP est un protocole de couche supérieure presque comme les autres.
Les paquets ICMP sont encapsulés dans un datagramme IP. Le champ protocole du paquet
IP porte la valeur : (01)h dans ce cas.

La différence réside dans le fait qu'IP pourra, de lui-même, passer une commande à ICMP
lorsque certains problèmes se produisent, sans qu'ICMP ait demandé quoique ce soit. Ce n'est
jamais le cas avec les autres protocoles de couches supérieures (TCP ou UDP) avec lesquels IP
ne discute que pour émettre ou recevoir des données.

Les formats des paquets ICMP varient selon le type d'informations à véhiculer. Nous ne les
présenterons pas ici. Il est plus intéressant d'étudier certaines fonctions et certains
mécanismes liés à ICMP. Sachez seulement que, dans tous les paquets, il existe un octet
d'entête indiquant à quel type de paquet ICMP nous avons à faire. Le tableau suivant liste les
principaux paquets ICMP utilisés :

Hexa Déc Message

00 0 Echo réponse
03 3 Destinataire inaccessible
04 4 Source quench
05 5 Redirection
08 8 Echo
0B 11 Temps dépassé
0C 12 Problème de paramètre
0D 13 Horloge
0E 14 Horloge response
0F 15 Demande d'information
10 16 Réponse d'information

Dans la suite de ce chapitre, nous allons étudier le rôle et quelques applications des paquets
"Echo / Echo Response", "Destination Unreachable", "Time Out" et "Redirect". Pour les
autres paquets, voici une description rapide :

• Source quench : permet à un équipement de réseau (généralement une passerelle) de

signifier à un émetteur une congestion du réseau, afin de solliciter un ralentissement
de l'émission. A noter qu'il n'existe aucune primitive permettant de relancer
l'émission, l'émetteur temporise l'émission de ses datagrammes tant qu'il reçoit des
indications de congestion. Une bonne implémentation d'IP va violemment ralentir son
émission à réception des paquets Source Quench, puis reprendre progressivement.
• Problème de paramètre : est émis par un récepteur ou une passerelle à l'émetteur
d'un paquet IP dont l'entête comporte une erreur rendant impossible l'exploitation du
paquet. Les erreurs de "checksum" ne sont pas traitées car dans de tels cas, l'adresse
IP de l'émetteur n'est pas forcément fiable ! Il s'agit en général d'erreurs dans les
options. Le paquet ICMP retourné comporte un champ "pointeur" qui indique la partie
du datagramme considérée en anomalie. Ce paquet sert très peu, car les options IP
sont très peu employées.
• Horloge / Horloge Response : Au départ ICMP avait été conçu pour permettre le calcul
des temps de traversée dans le réseau (délais de transit), afin de détecter d'éventuelles
 119

baisses de performances. Une autre fonction a ensuite été adjointe, permettant de

calculer les différences d'horloge entre les machines émettrices et réceptrices. Ce
paquet comporte des champs T1, T2, T3 et T4 permettant de stocker les instants
d'émission et réception des paquets aller et retour. Il suffit ensuite d'additionner et
soustraire ces champs pour obtenir le délai de transit. Ces paquets sont peu utilisés à
ma connaissance. En effet pour être efficace, ce protocole nécessite de synchroniser
les bases temps de tous les équipements IP d'un réseau. Cette synchornisation peut
être réalisée par un autre protocole nommé NTP (Network Time Protocol). Quoiqu'il
en soit, on peut très bien calculer les délais de transit autrement que par ces paquets
Horloge/Horloge Réponse, en utilisant le "ping" comme nous le verrons ci-après.
• Demande d'information / Réponse d'information : le seul cas d'utilisation de ces
paquets que je connaisse (sans jamais l'avoir vu à l'oeuvre !) est la récupération
d'adresse réseau. Similaire à RARP (que nous n'avons pas vu, mais qui permet à une
station de demander son adresse IP à partir de son adresse MAC), ces paquets
permettent à une machine de demander l'adresse réseau sur lequel elle se trouve. Le
paquet ICMP_INF_REQ est émis en broadcast et la réponse est fournie par toutes les
passerelles du réseau dans des paquets ICMP_INF_RESP. Si vous avez d'autres
exemples, n'hésitez pas à m'envoyer un mail !

Echo / Echo Response : Le ping !

C'est quoi ?

Si vous pratiquez IP, vous ne pouvez pas ignorer le fameux PING ! Tous les administrateurs IP,
et même les utilisateurs, sont des "pingueurs fous" ! La commande PING issue du monde Unix,
permet de tester l'accessibilité d'un équipement IP.

Sur pratiquement toutes les stations IP vous pouvez entrer la commande PING <adresse IP de
destination>. Vous recevrez ensuite des informations à l'écran, dont le format varie en
fonction des différentes implémentations. Ces informations vous renseignent sur votre
capacité à joindre ou non l'adresse visée.

Si vous ne connaissez pas cette fonction, un petit exemple, vaut mieux qu'un grand discours !
Si vous utilisez un PC sous Windows. Cherchez dans le menu Démarrer, la fonction Commande
MSDOS (souvent dans les accessoires). Dans la fenêtre (noire !), qui s''affiche entrez : ping
127.0.0.1 (vous pinguez qui là ? ... Si vous ne savez pas répondre, vous êtes recalé au partiel !).
En réponse vous obtiendrez selon le cas :
 120

• Request Timout : Pas de chance ! Le serveur ne répond pas ! C'est du moins ce que l'on dit
souvent, mais c'est un peu simpliste ! Nous allons y revenir ! Dans notre cas, vous n'obtiendrez
ce résultat que si vous n'avez pas de stack IP d'initialisé, ce qui m'étonnerai beaucoup puisque
vous êtes connecté à Internet pour lire cette page !
• 127.0.0.1 et des choses derrière ... : Le serveur répond ! Vous obtenez également des
informations sur le délai d'aller-retour pour atteindre le serveur.

Comment ça marche ?

Lorsque vous entrez la commande PING <@IP>, votre stack IP demande à ICMP d'émettre un
paquet Echo vers l'adresse destination :

l'émetteur formate un paquet ICMP_Echo comportant un numéro d'identification, un

numéro de séquence et quelques octets de données aléatoires. Selon les implémentations,
vous pouvez modifier les options de nombre d'octets pour visualiser le comportement du
réseau sur l'émission de gros paquets. Par exemple, sous Windows vous pouvez modifier la
taille par l'option -l.

le paquet ICMP est placé dans un paquet IP, d'adresse destination égale à celle que vous avez
indiqué et d'adresse source égale à celle de l'émetteur.

lorsque le paquet est émis, votre applicatif "pingueur" enclenche un timer

puis il émet un nouveau paquet ICMP_Echo du même format que le premier mais ayant un
numéro d'identification différent. Il enclenche également à son émission un timer associé au
paquet. Il peut répéter cette opération plusieurs fois. Sur Windows de base, le programme
émet trois paquets, cependant avec l'option -n vous pouvez modifier ce nombre.
 121

Pour connaître toutes les options du Ping de Windows, entrez simplement "ping" et validez
sous les Commandes MSDOS :

Les paquets ICMP_Echo, encapsulés dans des paquets IP, sont véhiculés à travers le réseau
jusqu'au destinataire. Quand le récepteur reçoit les paquets ICMP_Echo, il les transfére à son
programme ICMP. Celui-va répondre :

• il vérifie le checksum. Si celui-ci est correct, il n'y a pas d'erreur ! (Sans blagues ?). Il passe
donc à la séquence suivante, sinon il jette le paquet et ne répond pas.
• il formate un paquet ICMP_Echo_Response ayant les mêmes numéros d'identification et de
séquence ainsi que les mêmes données que le paquet Echo auquel il répond. Le numéro
d'identification permet de différencier des séquences Echo simultanément lancées depuis la
même machine vers le même destinataire (hyper rare !). Le numéro de séquence permet à
l'émetteur de repérer quel timer est associé à l'Echo_Response reçu. L'adresse IP source du
paquet IP permet de différencier plusieurs émetteurs d'Echo pour un même destinataire.
• le paquet ICMP est ensuite placé dans un paquet IP d'adresse source égale à l'adresse de la
station (le récepteur du paquet Echo.. Je précise pour ceux qui aurait du mal à suivre !) et
d'adresse destination égale à l'adresse source du paquet Echo précédemment reçu (qui ait
l'adresse de l'émetteur du ICMP_Echo... Je précise parce que j'en vois avec des yeux ronds dans
le fond à coté du radiateur !).

Le paquet ICMP_Echo_Response, encapsulé dans un paquet IP, est véhiculé à travers le réseau
jusqu'au destinataire. Quand celui-ci reçoit le paquet :

• il examine le checksum pour vérifier qu'il n'y a pas eu d'erreur. S'il détecte un erreur, le paquet
est détruit, le timer associé est interrompu et vous obtenez une ligne "Request TimeOut".
• si le checksum est bon, il examine le timer associé : si le timer est arrivé à expiration, le paquet
est détruit. Une ligne Request Time Out aura été préalablement retourné immédiatement à
expiration du timer.
 122

• si le timer est toujours valide, le programme retourne une ligne vous indiquant la valeur du
timer à la réception du paquet. Vous obtenez ainsi le délai de transit aller-retour du paquet.

La même opération est répétée pour tous les paquets.

Certaines implémentations d'IP retournerons une ligne à la fin de l'émission de tous les
paquets. Celle-ci indiquera le nombre de paquets perdus (non revenus avant expiration du
timer) ainsi que la valeur la plus faible, la plus grande et la moyenne du délai de transit.

La valeur du timer est souvent paramètrable, elle est par contre la même pour tous les paquets
d'une même séquence de "ping". En effet dans certains cas il peut être nécessaire d'adapter
ce timer (cas des liaisons satellites par exemple) à la configuration du réseau, sous peine de
n'obtenir que des Request TimeOut, les paquets arrivant tous après expiration d'un timer trop
court !

A quoi ça sert ?

Nous l'avons déjà dit : Le "ping" sert essentiellement à tester l'accessibilité d'un équipement
IP. Si vous avez des réponses positives à un "ping" vous savez que la route "aller" dans le
réseau, l'équipement visé et la route "retour" (qui peut être différente de la route "aller" !)
sont actifs.

Par contre si vous n'avez pas de réponses vous ne savez pas lequel de ces trois éléments
présente un défaut. Dans ce cas, vous allez étudier les tables de routage des passerelles pour
déterminer les chemins empruntés et vous allez ensuite "pinguer" chaque élement
(passerelle) de la route jusqu'à ce que vous trouviez lequel ne répond pas !

ATTENTION : IP fonctionne en mode non connecté et souvent on implémente dans le réseau

des politiques de routage dynamique. Ceci suppose que les passerelles choisissent les routes
en fonction de critères qui leurs sont propres. En conséquence, une route "aller" et une route
"retour" pour une même destination peuvent être différentes. La recherche d'un élément
défaillant dans le réseau (routeur ou lien) par des "ping" peut, dans ce cas, s'avérer trompeuse
si on ne maîtrise pas parfaitement le routage. Vous pouvez penser qu'un lien "aller" vers un
routeur est hors service, alors que c'est le lien "retour", comme dans l'exemple ci-dessous :

• Le "ping" depuis A vers B ne marche pas !

• Vous "pinguez" R1 sur son interface E0, il répond (normal vous êtes sur le même réseau local
!)
• Vous "pinguez" R2 sur son interface E0, il ne répond pas !
 123

Vous en déduisez que le problème se situe sur le lien entre R1 et R2 ou éventuellement sur
R2 !

C'est faux ! En fait, le problème se situe sur le retour R3 ! En effet R2 contacte le réseau
10.0.0.0 via R3 !

Donc ... Prudence avec les localisations de défauts par le "ping" !

Autres cas d'utilisation

Le ping peut également être utilisé pour :

• mesurer des délais de transit : Il existe des outils d'administrations qui demandent à des
routeurs d'émettre des "ping" et relèvent les résultats de délais de transit pour dresser des
tableaux de bords, par exemple.
• mesurer une fiabilité : En émettant des longues séquences de plusieurs centaines ou milliers
de paquets consécutifs (attention aux capacités de gestion des timers simultanés), vous pouvez
mesurer le nombre de paquets perdus et en déduire une fiabilité ou un taux de perte de
paquets.
• simuler une charge réseau pour évaluer l'impact sur les délais de transit et accessoirement en
déduire une bande passante bout en bout.

REMARQUES SUR LE DERNIER CAS :

Pour ce type de mesure on préfére souvent FTP, mais dans le cas des nouvelles architectures
ATM ce n'est pas toujours le meilleur choix ! En effet :

• vous ne contrôlez pas la taille des paquets émis par FTP, celui-ci ayant tendance à remplir au
maximum les segments TCP en fonction de la taille de la MTU locale (celle du LAN sur lequel
l'émetteur est placé). Cette taille peut être différente de celle qu'utilise votre application
usuelle et dont vous voulez simuler le comportement. Par des "ping" vous pouvez fixer la taille
des paquets afin de vous rapprocher de la taille de ceux émis par votre application.
• En ATM, la gestion de la bande passante est dynamique, c'est à dire que vous avez un débit
minimum garanti mais vous pouvez le dépasser (on parle de "bursts"). Pour cela vous
remplissez plus ou moins de cellules ATM dans le train binaire qui se présente. Par contre si
vous dépassez trop longtemps le débit mini, vos cellules sont marquées comme candidates à
 124

la suppression (on dit qu'on les "tag"). Si le réseau est surchargé, ces cellules sont supprimées
(on dit qu'on les "drop"). Or si une cellule manque, le paquet IP est corrompu (ne parlons pas
de la couche AAL5 !), le segment TCP véhiculant le FTP est donc corrompu, et il y a
retransmission au niveau TCP ! Mais en ATM les cellules sont toutes petites (48 ou 47 octets
utiles selon le cas) et si votre paquet a été coupé en 10 cellules et qu'une seule a été "droppée",
vous perdez le tout et il faut tout réémettre ! Votre transfert FTP prend donc plus de temps,
donc votre débit utile vous semble plus petit ! En fait, vous avez simplement dépassé votre
contrat de trafic et vous avez enclenché les mécanismes de limitations (on appelle ça du
"shapping") ! Si vous faites le même test en TFTP (supporté par UDP, en mode non connecté,
sans reprise sur erreur) ou en utilisant le "ping" ICMP il est fort probable que vous mesuriez
une bande passante plus conséquente !! Etonnant non ?

Destination inaccessible !
Nous avons vu dans les chapitres précédents, que les maîtres du routage dans un réseau IP,
sont les routeurs (ou passerelles). Ceux-ci routent les paquets en se construisant des tables
de routage qui dressent la cartographie du réseau. Le routeur est un "bison futé", il sait à tous
moments quelle est la meilleure route pour atteindre une destination !

Mais parfois "bison futé" a des défaillances ! Vous avez tous, un jour de grande affluence, au
moment des départs en vacance, suivi un "Itinéraire Vert". Certes il était vert dans le sens où
il vous a amené en pleine campagne ! Mais vous avez ensuite vu rouge quand il vous a largué
en plein milieu de "Trou de nulle part" sans aucun panneau pour retrouver son chemin ! Et
bien, IP c'est pareil ! Un paquet peut très bien aboutir sur une passerelle qui ignore tout du
chemin à emprunter pour atteindre le réseau inscrit en adresse destination !

Mais la passerelle sait reconnaître ses erreurs (ce qui n'est pas le cas de "bison pas futé" !),
elle envoie à l'émetteur un paquet ICMP Destination Unreachable !!

L'émetteur est ainsi informé que le paquet n'a pas pu être délivré et que la destination est
incontactable. Que fait IP ? ... Rien ! S'en fiche ! Selon l'implémentation il pourra
éventuellement informer la couche supérieure que son correspondant est parti se coucher !
A elle de décider ce qu'elle veut faire ! TCP va insister grossiérement en relançant ses
informations jusqu'à ce qu'il admette enfin que le destinataire est VRAIMENT incontactable.
UDP, un peu fainéant ne fera rien !

Le paquet ICMP Destination Unreachable permet d'informer plus précisément l'émetteur sur
la cause de la non délivrance du paquet. Un octet de code dans le paquet permet d'indiquer :

Réseau inaccessible (code 0) : si la destination est inaccessible parce que le réseau n'est pas
déclaré dans une table de routage d'une des passerelles traversé par le paquet IP

Host inaccessible (code 1) : si la station de destination est incontactable. Le paquet a bien

atteint le réseau de destination, mais aucune station n'a répondu à la requête ARP de la
passerelle du réseau de destination.

Protocole inaccessible (code 2) : retourné par la station de destination, si le champ Protocole

du paquet IP indique un protocole de niveau supérieur non géré par la station. Par exemple si
 125

vous envoyez des données IGRP (protocole de routage) à une station qui n'est pas un routeur
Cisco !

Port inaccessible (code 3) : retourné par une station qui reçoit un paquet IP, véhiculant un
message TCP ou UDP dont le numéro de port destination est inconnu de la station (Là, c'est
du niveau 4 ! Laissez tomber ...).

Fragmentation nécessaire, mais interdite (code 4) : retourné par une passerelle qui doit
fragmenter un paquet, pour pouvoir l'encapsuler dans une trame dont la MTU est inférieure
à la taille du paquet, mais qui ne peut le faire car le bit DF (Don't Fragment) du paquet est
positionné à 1 ! Le paquet est jeté, et le paquet ICMP est envoyé à la station. Cette technique
est utilisée par TCP lorsqu'il tente de découvrir la taille minimum de la MTU sur une route
(j'en ai briévement parler dans le chapitre précédent !). TCP émet d'abord un paquet à la taille
de la MTU du réseau local, s'il reçoit un ICMP Destination Unreachable code 4, il diminue la
taille et ainsi de suite !

Echec du source routing (code 5) : laissez tomber ! Ce sera trop long ! Sachez que ce message
est lié au champ Option du paquet IP qui permet de mettre en place un routage imposé par la
source. L'émetteur indique par quelles passerelles doit passer le paquet ... Bref ! Assez peu
utilisé !

Pas mal ICMP Destination Unreachable ? On en apprend des choses, hein ?

Time Out : Le TTL est mort !

C'est quoi ?

Nous avons vu précédemment que l'entête du paquet IP présentait un champ nommé TTL
(Time To Live). Lorsque dans le chapitre précédent nous avons étudié la fragmentation, nous
avons évoqué ce champ et la manière dont il était géré par les machines IP. Pour rappel :

• le TTL permet d'indiquer une durée de vie à un paquet IP afin d'éviter que le réseau continue
d'acheminer des paquets perdus
• ce TTL est généralement fixé à 255 mais peut être géré par l'émetteur pour diminuer la portée
d'un paquet
• un routeur décrémente de 1 le TTL de tous paquets qui le traversent
• lorsqu'un paquet est placé en file d'attente, que ce soit dans un routeur ou dans une station à
l'émission ou à la réception, le TTL est décrémenté de 1 toutes les secondes.
• La machine qui passe à 0 le TTL détruit le paquet correspondant.

En conséquence, une station ou un routeur peut avoir à passer le TTL d'un paquet à 0. Celui
qui réalise cette opération enverra un paquet ICMP_TIME_OUT à l'émetteur du paquet pour
l'informer de sa destruction. Encore une fois, ce n'est pas IP qui réagira, il transmettra
l'information aux couches supérieures qui décideront de la conduite à tenir.
 126

L'application au Trace Route

Nous avons précédemment évoqué le "ping" comme une commande très utile pour
l'administration d'un réseau IP. Une autre commande très utilisée par les fous d'IP, est le
TRACE ROUTE.

Le "trace route", comme son nom l'indique, permet de tracer la route empruntée par un
paquet IP pour atteindre sa destination. En lançant cette commande vous recevez en réponse,
la liste des passerelles par lesquelles est passé le paquet. Ce programme utilise la gestion du
TTL et le mécanisme de l'ICMP_TIME_OUT !

Le principe est le suivant :

• vous entrez sur votre équipement IP la commande trace route <@IPdest>

• le programme Trace route formate un paquet IP d'@IPsource égale à votre station et
d'@IPdest égale à celle indiquée dans la ligne de commande. Le TTL du premier paquet est
fixé à 1 (au lieu de 255).
• le paquet est émis vers la Gateway Default de votre station pour être routé dans le réseau
• quand le routeur reçoit le paquet il décrémente de 1 le TTL. Il le passe donc à 0, puisqu'il été
fixé à 1 !
• le routeur détruit donc le paquet et émet un paquet ICMP_TIME_OUT vers l'émetteur du
paquet. Ce paquet est encapsulé dans un paquet IP ayant pour adresse source l'adresse de
l'interface de sortie du routeur vers votre station.
• l'émetteur reçoit le paquet ICMP émis dans le paquet IP. Le paquet IP a pour adresse source
l'adresse de la passerelle qui a détruit le paquet. Il peut donc vous renvoyez une ligne à l'écran
vous indiquant l'adresse de la première passerelle traversée par le paquet.
• puis l'émetteur formate un deuxième paquet IP avec un TTL fixé à 2. Cette fois le premier
routeur va passer le TTL à 1 et enverra le paquet au prochain routeur indiqué dans sa table de
routage, pour la route concernée par le paquet IP.
• le deuxième routeur passe le TTL à 0 et retourne donc un ICMP_TIME_OUT qui sera reçu par
l'émetteur, etc ...
• le process est terminée lorsque le paquet atteint la station de destination. En effet dans ce
cas, l'adresse source du paquet IP véhiculant le paquet ICMP_TIME_OUT est la même que
l'adresse indiquée dans la ligne de commande du "trace route".
 127

Chaque passerelle de la route empruntée par les paquets IP pour atteindre l'adresse
destination, aura donc, au final, transmis un paquet ICMP_TIME_OUT dans un paquet IP ayant
pour adresse source l'adresse de l'interface de sortie du routeur. Vous avez ainsi le chemin
emprunté !

Quelques petites précisions

Lorsque le programme "trace route" émet un paquet il lui associe un timer (un peu comme
dans le ping). Ce timer permet de mesurer le délai aller-retour pour atteindre la passerelle qui
placera le TTL à 0. Vous pouvez ainsi obtenir le délai de transit, tronçon par tronçon pour
une direction donnée. Le timer permet également de stopper le processus lorsque la route
est invalide et que les passerelles ne répondent pas (dans ce cas même un "ping" ne passerai
pas, bien sûr !).

La station émettrice peut émettre simultanément des paquets IP de données et des paquets
relevant pas du programme trace route pour une même destination. Ces paquets pourrait très
bien avoir leur TTL placé à 0 pendant le trajet, pour une raison quelconque. La machine IP qui
passerai ce TTL à 0, retournera également un ICMP_TIME_OUT ! Comment l'émetteur peut-il
différencier les ICMP_TIME_OUT relevant du process "trace route" des paquets relevant du
transfert de données utiles ? En fait, lorsqu'une station formate un ICMP_TIME_OUT elle
recopie dans ce paquet l'entête et les 8 premiers octets du paquet IP qu'elle détruit. Il y a
donc suffisament d'information dans ce paquet pour que la station émettrice du paquet
détruit puisse identifier le paquet concerné.

Le message ICMP_TIME_OUT permet de différencier deux causes de destruction du paquet

par expiration du TTL, grâce à un octet de code :
 128

• Champ TTL épuisé (code 0) : est indiqué lorsqu'une machine IP a reçu le paquet avec un TTL à
1 et a donc dû le placer à 0. On suppose qu'une boucle dans le réseau a fait tourné le paquet
trop longtemps.
• Attente trop longue au réassemblage (code 1) : est indiqué par une machine qui détruit un
paquet IP parce qu'elle n'a pas reçu dans les temps tous les fragments permettant de le
reconstituer. Ce code est donc forcément émis par le destinataire du paquet (et pas par une
passerelle) puisque seul le destinataire opére le réassemblage

Redirect : Tu te trompes de route !

La Gateway de sortie du LAN

Nous avons étudié au chapitre 5, les bases du routage IP. Dans le paragraphe "Sortir du
réseau" nous avons expliqué comment une station contactait sa passerelle de sortie (Gateway
Default) pour émettre des paquets en dehors du réseau local.

Mais que se passe-t-il s'il y a plusieurs routeurs sur le LAN, chacun d'eux desservant une ou
des destination(s) particulière(s) ?

Peu de stations offrent la possibilité de déclarer une passerelle spécifique pour une route
donnée ! A ma connaissance, seules les stations Unix (et sûrement Linux !) permettent de
définir une table de routage au sein d'un host IP qui n'est pas une passerelle :

• En environnement Windows 95 vous ne pouvez définir qu'une passerelle par défaut qui sera
systématiquement utilisée pour acheminer le trafic sortant du LAN (Merci Bilou ! Tu ne nous
simplifie pas la vie, tu sais ?).
• En environnement Windows NT 4 et 5 Workstation vous pouvez définir sur une station
plusieurs Gateway Default ! Mais pas pour des routes spécifiques ! Si la passerelle par défaut
passe hors service alors qu'elle a déjà été utilisée par la station (la correspondance ARP est
mémorisée), il faudra rebooter la station pour pouvoir utiliser la deuxième Gateway
(Franchement Bilou ! A quoi tu penses ? ).
• En environnement NT 4 et 5 Server (peut-être NT 3 aussi !), vous pouvez définir une table de
routage dans le serveur (Enfin Bilou ! Il était temps de te réveiller !).

Le problème

Donc, comme dans le schéma suivant, supposons que A veuille émettre un paquet à B. A a
pour Gateway Default R1, qui malheureusement ne peut pas desservir le réseau de B (pas de
chance !).
 129

Mais R1 n'est pas totalement stupide ! Dans sa table de routage il voit bien que B peut être
atteint en passant par R2 (enfin, si votre plan de routage est bien fait !) ! Quand R1 recevra le
paquet à destination de B, il va donc le transmettre à R2 !

Mais R1 n'aime pas travailler pour rien ! Il a bien remarqué, qu'il a été obligé de réémettre le
paquet par l'interface sur laquelle il l'a reçu ! Il se dit donc, bien légitimement, que si A été un
peu moins stupide il aurait envoyé son paquet directement à R2 !

La solution

Heureusement R1 (bonne âme !) va tenter d'instruire A en lui émettant un paquet

ICMP_Redirect, lui donnant l'adresse de Gateway à contacter pour émettre vers le réseau de
B!

A va mettre à jour sa table de routage ! Au prochain paquet à émettre vers le réseau de B, il

lancera une séquence ARP pour connaître l'adresse MAC de R2, puis lui enverra le paquet !

Super non ? ... Pas tant que ça ! Réfléchissons !

L'impact négatif

Nous venons d'admettre que l'ICMP_Redirect a pour effet de mettre à jour la table de routage
de l'émetteur ! Mais nous avons aussi dit que peu de stations gérent une table de routage (les
serveurs NT et les serveurs et stations Unix !). Autrement dit, seul ce type d'équipement IP (en
dehors des passerelles bien sûr !), exploiterons l'ICMP_Redirect ! Toutes les autres stations
vont continuer (bêtement !) d'émettre leur paquet à la Gateway Default !

Dans cette configuration, à chaque fois la passerelle va donc émettre un ICMP_Redirect, après
avoir émis le paquet à la bonne passerelle ! Donc au total trois paquets sont émis sur le LAN
alors qu'il ne devrait y en avoir qu'un !! (Le LAN est super content ! Cela occupe sa bande
 130

passante, qui justement s'ennuyait !!). Bien sûr ce fonctionnement a un impact sur les délais
de transit puisque le paquet traverse un routeur de trop (R1) et deux fois le LAN au lieu d'une
fois !

Dans un cas d'exploitation réel, j'ai l'exemple d'un client qui a gagné 20% sur ses délais de
transit en modifiant la Gateway de ses serveurs. A priori la fonction ICMP_Redirect n'était pas
active sur ses routeurs, ou plutôt son serveur n'interprétait pas les paquets ICMP_Redirect !

Une solution pour résoudre le problème

Il n'y a pas beaucoup de solutions pour améliorer ce fonctionnement. Le problème est qu'un
routeur est obligé de réémettre un paquet sur le LAN par lequel il l'a reçu !

Si vous désactivez l'ICMP_Redirect sur vos routeurs, vous n'aurez plus de paquets ICMP sur le
LAN mais vous aurez toujours le rebond entre routeurs par le même LAN !

La seule solution est donc d'interconnecter les routeurs entre-eux (on appelle ça une liaison
"back to back" !) et de déclarer l'un des routeurs (disons, R1 ?) en Gateway Default ! Dans le
schéma suivant, comme précédemment, A envoie son paquet pour B à R1, R1 le renvoi à R2
par le lien R1-R2 et non pas par le LAN ! Donc plus d'ICMP_Redirect et plus de double charge
du LAN !

Le problème est où cette fois ? ... Qu'arrive-t-il si R1 est HS ? Plus personne ne sort du réseau
quelque soit la destination demandée ! Mais on ne peut pas tout voir dans ce cours ! J'ai aussi
le droit de garder quelques petits trucs pour les prochains ! Rassurez-vous, il y a des solutions
! Mais ce sera pour un cours sur le routage !
 131

Quelques petites précisions

Comme pour le paquet ICMP_Destination_Unreachable, le paquet ICMP_Redirect posséde

un octet de code qui permet de préciser la nature de la redirection :

• rediriger pour le réseau demandé (code 0) : le plus courant. Dans notre exemple nous avons
dit que R1 retournait à A un Redirect pour le réseau de B (pas pour la station). En effet R1 a
bien remarqué, dans sa table de routage, que R2 desservait tout le réseau de B.
• ne rediriger que pour le host demandé (code 1) : nous n'en avons jamais parlé, mais vous
pouvez très bien définir, dans une table de routage, une route spécifique pour une station
spécifique, au lieu d'un réseau complet. Cela est parfois employé pour l'accès des stations
d'administrations à qui on attribue une route spéciale avec accès par RNIS, par exemple. Donc
si B avait eu une route dédiée dans la table de routage de R1, celui aurait retourné un Redirect
code 1.
• ne rediriger que pour le réseau et le TOS demandés (code 2) : nous avons peu évoqué le TOS
(Type Of Service) qui est encore très peu utilisé. Ce champ, placé dans l'entête IP, permet
d'indiquer une priorité à un paquet. Certains protocoles de routage, comme OSPF, permettent
de dresser des tables de routage différentes en fonction des TOS. Autrement dit, les routes de
deux paquets IP pour un même destinataire, mais ayant des champs TOS différents, peuvent
être différentes ! Le Redirect permet de tenir compte de cette particularité en indiquant que
la redirection est uniquement valable pour les paquets ayant un TOS et une destination
identique.
• ne rediriger que pour le host et le TOS demandés (code 3) : vous avez bien compris que code
3 = code 1 mais en ajoutant le critère du TOS !

Afin que la station émettrice identifie le paquet pour lequel elle reçoit un ICMP_Redirect, le
routeur recopie dans l'ICMP l'entête IP et les 8 premiers octets de données du paquet qu'il
place en redirection. Ainsi la station émettrice peut notamment retrouver l'adresse IP de
destination en cause !

Conclusion du chapitre
Et voilà ! Nous en avons terminé avec cette présentation sommaire des principales fonctions
d'ICMP. J'ai tenu à illustrer certaines d'entre-elles par des cas réels d'utilisation car il n'est pas
toujours évident d'en comprendre l'utilité !!

Il reste un grand flou sur la manière dont les stations émettrices exploitent les informations
transmises par ICMP. Les programmes "ping" et "trace route" sont clairs, mais restent des
programmes essentiellement dédiés à l'administration. Un "ping" ou un "trace route" n'a pas
de réelle valeur sur un transfert de données utiles. Ce que fait une station lorsqu'elle reçoit
un ICMP Source Quench, un ICMP Time_Out, ou un quelconque autre ICMP, dépendra :

• de l'implémentation IP mise en oeuvre dans le stack installé sur la machine (existe-t-il des
primitives pour remonter les informations aux couches supérieures ?)
• de l'implémentation des couches TCP et UDP du stack installé (si des primitives ICMP
remontent d'IP, TCP et UDP en tiennent-ils compte ?)
• de l'implémentation des applications de couches supérieures (si TCP ou UDP retournent des
informations issues des primitives ICMP, les applications les exploitent-elles ?).
 132

J'avoue manquer d'informations sur le sujet !

IP se termine avec ce chapitre ! Il y a sans aucun doute beaucoup de choses à dire encore,
mais l'essentiel a été présenté ! Le reste viendra avec l'expérience ! Sur les prochains cours, je
pense m'attacher plus aux principes de routages IP, qui est un sujet véritablement passionnant
!

CHAPITRE 12 : UN PETIT RESUME !

Le résumé
Introduction
Lors de ce cours nous avons abordé quantité de concepts qui dans leur globalité peuvent vous
sembler un peu confus. Chacun d'eux pris isolément vous apparaissant clairement, mais leur
imbrication dans un dialogue IP pouvant être plus nébuleuse !

Je vous propose donc à travers ce chapitre, sans reprendre dans le détail l'ensemble des
points, de tenter de synthétiser les mécanismes IP. Pour cela je vous propose :

• un organigramme de traitement de l'émission d'un paquet IP par une station

• un organigramme de traitement du transfert d'un paquet IP par une passerelle
• un organigramme du traitement de la réception d'un paquet IP
• un exemple des différents mécanismes enclenchés pour transmettre un paquet IP à travers
un réseau simple

Ces quatres points devraient, je l'espère, "vous remettre les yeux en face des trous" !
 133

Traitement de l'émission d'un paquet IP

L'organigramme ci-contre synthétise le fonctionnement du stack IP à l'émission d'un paquet
depuis la transmission par la couche supérieure, jusqu'à l'encapsulation dans une trame.

Toutes les fonctions n'y sont pas représentées notamment le traitement des redirections
ICMP.

Vous noterez le principe de détection d'un paquet à destination d'un autre réseau par
comparaison avec l'adresse IP et le masque de la station.

Vous noterez également le traitement ARP sur l'adresse de Gateway ou sur l'adresse du
destinataire si celui-ci est dans le même réseau que l'émetteur.

La fragmentation n'est pas détaillée mais la majorité des stacks IP essaie de l'éviter au niveau
de l'émetteur. Il suffit que les couches supérieures aient connaissance de la MTU locale.
 134

Traitement du transfert d'un paquet

Cet organigramme reprend en partie celui qui vous a été présenté dans le chapitre 5. Il
synthétise le fonctionnement d'un routeur à réception d'un paquet IP.

Encore une fois toutes les fonctions de routage ne sont représentées. Vous noterez :

• le traitement du routage notamment avec le principe du routage par défaut

(Route_Default)
• le traitement de l'ARP que ce soit pour atteindre le destinatoire final ou pour atteindre
un routeur voisin qui se situerait sur le même LAN.
 135

• la gestion du TTL (je n'ai pas traité la gestion du TTL sur des paquets en file d'attente).
• le traitement de la fragmentation avec la prise en compte du bit DF.
• les principaux cas d'émission de messages ICMP. Nous n'avons pas traité le cas de
l'ICMP_Source_Quench en cas de congestion du lien de sortie.

Traitement de la réception d'un paquet IP

Cet organigramme présente l'algorythme déroulé par une station qui reçoit un paquet IP.

Toutes les fonctions ne sont pas détaillées, notamment les traitements d'erreurs activant les
fonctions ICMP.

Vous remarquerez le contrôle du checksum qui a lieu avant la lecture de l'adresse IP. Ce
contrôle est également effectué dans les routeurs. Je n'ai pas fait apparaître ce traitement
dans l'organigramme précédent.

Vous remarquerez également le principe de détection des fragments de paquets (bit MF et

valeur de l'Offset). Ce traitement n'est réalisé qu'en réception.
 136

J'attire également votre attention sur le traitement du TTL des fragments en attente et sur le
traitement du champ Protocole.

Exemple de transfert IP
Je simule ici l'émission d'un "ping" depuis A vers B. Les paquets traversent R1, R2 et R4 à l'aller
puis R4 et R3 au retour. Ce parcours étonnant est tout à fait réaliste croyez-moi !

Le but est ici de montrer le fonctionnement global du routage IP à travers un réseau

"tournant" en interaction avec ARP. On suppose que le réseau était hors tension, qu'on
"l'allume' et que A émet tout de suite son PING. Les tables de routages des routeurs ont été
inscrites en statique (à la main !).

La station A commence par émettre une séquence ARP puisqu'elle ne connaît pas l'adresse
MAC de sa Gateway.

Entre R1 et R2 il n'y a pas d'ARP car ils sont interconnectés par un lien série ! Toute trame
émise à un bout abouti à un seul destinataire (celui de l'autre bout !).

Entre R2 et R4 il y a une séquence ARP pour que R2 découvre l'adresse MAC de la trame à
destination de R4.

R4 réalise une séquence ARP vers B. Au retour vous remarquerez que B ne fait pas de séquence
ARP vers R4 car elle aura pu profiter (ce n'est pas sûr à 100% ! A vérifier !) de la séquence ARP
précédente de R4 pour apprendre son adresse MAC.
 137

Au total il aura fallu 15 trames de niveau 2 pour véhiculer ce premier paquet de ping aller-
retour ! Par contre le prochain paquet ne nécessitera plus que 7 trames ! Pourquoi ? (Attention
à vos réponses ! Sinon vous vous inscrivez en deuxième semaine !).

Conclusion du chapitre
Finalement, IP c'est pas si dur, n'est-ce pas ?

J'espère que cette synthèse vous aura aidé ! Et comme je suis sympa je vous offre les
organigrammes au format PowerPoint : orga.zip (14 Ko)

CONCLUSION : C'EST LA FIN !

138