ICMP est l’acronyme de “ Internet Control Message Protocol ”, il est historiquement d´efini dans la RFC 950.
Nous avons vu que le protocole IP ne v´erifie pas si les paquets ´emis sont arriv´es `a leur destinataire dans de bonnes conditions.
Les paquets circulent d’une passerelle vers un autre jusqu’`a en trouver une qui puisse les d´elivrer directement `a un hˆote. Si une passerelle ne peut router ou d´elivrer directement un paquet ou si un ´evenement anormal arrive sur le r´eseau comme un trafic trop important ou une machine indisponible, il faut pouvoir en informer l’hˆote qui a ´emis le paquet. Celui-ci pourra alors r´eagir en fonction du type de probl`eme rencontr´e.
ICMP est un m´ecanisme de contrˆole des erreurs au niveau IP, mais la figure II.02 du chapitre d’introduction `a IP (page 23) montre que le niveau Application peut ´egalement avoir un acc`es direct `a ce protocole.
4.1 Le syst` eme de messages d’erreur
Dans le syst`eme que nous avons d´ecrit, chaque passerelle et chaque hˆote op`ere de mani`ere autonome, route et d´elivre les datagrammes qui arrivent sans coordination avec l’´emetteur.
Le syst`eme fonctionne parfaitement si toutes les machines sont en ordre de marche et si toutes les tables de routage sont `a jour. Malheureusement c’est une situation id´eale. . .
Il peut y avoir des rupture de lignes de communication, des machines peuvent ˆetre `a l’arrˆet, en pannes, d´econnect´ees du r´eseau ou incapables de router les paquets parcequ’en surcharge.
Des paquets IP peuvent alors ne pas ˆetre d´elivr´es `a leur destinataire et le protocol IP lui-mˆeme ne contient rien qui puisse permettre de d´etecter cet
´echec de transmission.
C’est pourquoi est ajout´e syst´ematiquement un m´ecanisme de gestion des erreurs connu sous le doux nom de ICMP. Il fait partie de la couche IP5 et porte le num´ero de protocole1.
Ainsi, quand un message d’erreur arrive pour un paquet ´emis, c’est la couche IP elle-mˆeme qui g`ere le probl`eme, la plupart des cas sans en informer les couches sup´erieures (certaines applications utilisent ICMP6).
Initialement pr´evu pour permettre aux passerelles d’informer les hˆotes sur des erreurs de transmission,ICMPn’est pas restreint aux ´echanges passerelles-hˆotes, des ´echanges entres hˆotes sont tout `a fait possibles.
Le mˆeme m´ecanisme est valable pour les deux types d’´echanges.
5voir ou revoir lafigure II.02 du chapitre d’introduction `a IP (page 23)
6Mˆeme figure qu’au point pr´ec´edent
Protocole ICMP 57
4.2 Format des messages ICMP
Chaque message ICMP traverse le r´eseau dans la partie DATA d’un da-tagramme IP :
En−tete IP Message ICMP
figure IV.09 — Message ICMP
La cons´equence directe est que les messages ICMP sont rout´es comme les autres paquets IP au travers le r´eseau. Il y a toutefois une exception : il peut arriver qu’un paquet d’erreur rencontre lui-mˆeme un probl`eme de transmission, dans ce cas on ne g´en`ere pas d’erreur sur l’erreur !
Il est important de bien voir que puisque les messages ICMP sont encap-sul´es dans un datagrammeIP,ICMP n’est pas consid´er´e comme un protocole de niveau plus ´elev´e.
La raison de l’utilisation d’IPpour d´elivrer de telles informations, est que les messages peuvent avoir `a traverser plusieurs r´eseaux avant d’arriver `a leur destination finale. Il n’´etait donc pas possible de rester au niveau physique du r´eseau (`a l’inverse de ARPou RARP).
La figure IV.10 d´ecrit le format du message ICMP :
0 7 8 15 16 31
CODE CHECKSUM
TYPE
EN−TETE du message original
..
figure IV.10 — Format d’un message ICMP
Chaque message ICMP a un type particulier qui caract´erise le probl`eme qu’il signale. Un en-tˆete de 32 bits est compos´e comme suit :
TYPE contient le code d’erreur.
CODE compl`ete l’information du champ pr´ec´edent.
CHECKSUM est utilis´e avec le mˆeme m´ecanisme de v´erification que pour les datagrammesIP mais ici il ne porte que sur le message ICMP (rappel : le checksum de l’en-tˆete IP ne porte que sur son en-tˆete et non sur les donn´ees v´ehicul´ees).
En addition, les messagesICMPdonnent toujours l’en-tˆeteIPet les 64 pre-miers bits (les deux prepre-miers mots de quatre octets) du datagramme qui est `a l’origine du probl`eme, pour permettre au destinataire du message d’identifier quel paquet est `a l’origine du probl`eme.
4.3 Quelques types de messages ICMP
Ce paragraphe examine quelques uns des principaux types de messages ICMP, ceux qui sont le plus utilis´es. Il existe onze valeurs deTYPE diff´erentes.
“ Echo Request (8), Echo reply (0) ” Une machine envoie un message ICMP “ echo request ” pour tester si son destinataire est accessible.
N’importe quelle machine qui re¸coit une telle requˆete doit formuler un messageICMP “ echo reply ” en retour7
Ce m´ecanisme est extrˆemement utile, la plupart des impl´ementations le propose sous forme d’un utilitaire (pingsous Unix).
Echo request(8) IP
IP Echo reply(0)
Y
A B
figure IV.11 — “ Echo request ” vs “ Echo reply ”
“ Destination Unreachable (3) ” Quand une passerelle ne peut pas d´elivrer un datagramme IP, elle envoie un message ICMP “ destination unreachable ” `a l’´emetteur.
Dans ce cas le champ CODE compl`ete le message d’erreur avec : 0 “ Network unreachable ”
1 “ Host unreachable ” 2 “ Protocol unreachable ” 3 “ Port unreachable ”
4 “ Fragmentation needed and DF set ” 5 “ Source route failed ”
“ Source Quench (4) ” Quand un datagramme IP arrive trop vite pour une passerelle ou un hˆote, il est rejet´e.
Un paquet arrive “ trop vite ” quand la machine qui doit le lire est congestionn´ee, trop de trafic `a suivre.. . .
Dans ce cas la machine en question envoie un paquet ICMP “ source quench ” qui est interpr´et´e de la fa¸con suivante :
L’´emetteur ralenti le rythme d’envoi de ses paquets jusqu’`a ce qu’il cesse de recevoir ce message d’erreur. La vitesse est donc ajust´ee par une sorte d’apprentissage rustique. Puis graduellement il augmente le d´ebit, aussi longtemps que le message “ source quench ” ne revient pas .
7Pour des raisons de s´ecurit´e certaines machines peuvent ne pas r´epondre.
Protocole ICMP 59 Ce type de paquetICMPa donc tendance `a vouloir r´eguler le flux des
da-tagrammes au niveau IP alors que c’est une fonctionnalit´e de la couche de transport (TCP).
C’est donc une s´erieuse entorse `a la r`egle d’ind´ependance des couches.
“ Redirect (5) ” Les tables de routage (Voir le paragraphe 6) des stations restent assez statiques durant de longues p´eriodes. Le syst`eme d’exploi-tation les lit au d´emarrage sur le syst`eme de fichiers et l’administrateur en change de temps en temps les ´el´ements.
Si entre deux modifications une destination change d’emplacement, la donn´ee initiale dans la table de routage peut s’av´erer incorrecte.
Les passerelles connaissent de bien meilleures routes que les hˆotes eux-mˆemes, ainsi quand une passerelle d´etecte une erreur de routage, elle fait deux choses :
1. Elle envoie `a l’´emetteur du paquet un message ICMP “ redirect ” 2. Elle redirige le paquet vers la bonne destination.
Cette redirection ne r`egle pas les probl`emes de routage car elle est li-mit´ee aux interactions entres passerelles et hˆotes directement connect´es.
La propagation des routes aux travers des r´eseaux multiples est un autre probl`eme.
Le champ CODEdu message ICMP peut avoir les valeurs suivantes : 0 “ Redirect datagram for the Net ”
1 “ Redirect datagram for the host ” 2 . . .
“ Router solicitation (10) vs Router advertisement (9) ” Il s’agit d’obtenir ou d’annoncer des routes, nous verrons cela plus en d´etail dans le paragraphe 6.4.
“ Time exceeded (11) ” Chaque datagramme contient un champ TTL dit “ TIME TO LIVE ” appell´e aussi “ hop count ”.
Afin de pr´evenir le cas ou un paquet circulerait `a l’infini d’une passerelle
`a une autre, chaque passerelle d´ecr´emente ce compteur et rejette le paquet quand le compteur arrive `a z´ero et envoie un message ICMP `a l’´emetteur pour le tenir au courant.