Chronologie globale Documents historiques A venir: les newsgroups, le protocole UUCP, Craig's List, Amazon, eBay, Facebook, Youtube, ... A venir: RSS, Javascript, Google, Wikipedia, AOL, UUNet, le spam, ... et bien d'autres secrets ...
Dès septembre 1981, Jon Postel publie le document RFC792 relatif au protocole ICMP ("Internet Control Message Protocol"). Intercalé entre les documents RFC791 ("Internet Protocol") et RFC793 ("Transmission Control Protocol"), il pose les bases d'un protocole destinée au contrôle des échanges de paquets en mode commuté. Initialement, les routeurs utilisaient le protocole GGP ("Gateway to Gateway Protcol") pour contrôler les flux de données transmis. Jon Postel souhaita alors implémenter un protocole de contrôle plus simple et intégré directement au coeur du protocole IP.
Agissant comme un protocole de niveau supérieur, ICMP est pourtant intégré au protocole IP. Les messages ICMP sont utilisés par les équipements pour la notification de tout erreur relatives à la gestion des flux de données. Par ailleurs, le protocole n'est pas sûr et ne garantit ni l'émission des messages, ni leur réception. L'implémentation de mécanismes garantissant les communications doit toujours être confiée aux protocoles des couches supérieures, tels que TCP.
Le protocole ICMP diffère de ses cousins TCP et UDP dans la mesure où ces derniers sont utilisés pour émettre et recevoir des paquets de données entre équipements finaux. ICMP assure quant à lui la gestion des messages concernant deux équipements proches, comme par exemple des routeurs.
Les paquets ICMP sont encapsulés dans des paquets IP avec un entête spécifique afin de permettre le renvoi du paquet vers l'équipement émetteur du paquet. Lorsqu'un équipement traite un paquet IP, il décrémente un champ de l'entête IP nommé TTL ("Time To Live"). Si la valeur du champ TTL équivaut à 0, un message ICMP spécifique du type "Time to live exceeded in transit" est alors renvoyé à l'équipement qui a émis le paquet lui indiquant que le paquet n'a pas pû être émis car sa durée de vie est expirée.
Il est assez peu commun qu'une application logicielle utilise le protocole ICMP puisqu'il est réservé au traitement des messages d'erreurs. Cependant, deux outils bien connus des administrateurs système et réseau ont été spécifiquement conçu dans ce cadre : il s'agit des outils nommés 'Ping" et "Traceroute" :
L'utilitaire "Ping" a été développé en décembre 1983 par Mike Muuss, alors chercheur au Laboratoire de Recherche Balistique de l'armée américaine, pour l'aide au diagnostic des problèmes réseau. Mike Muss l'a nommé ainsi par analogie avec les impulsions sonores émises par les radars, dont le principe est similaire, l'onde radar étant ici remplacée par un paquet ICMP. Le mot "Ping" est à présent aussi utilisé comme verbe (exemple: "il ping mon routeur") mais aussi substantif (exemple: "ton ping montre que le serveur web est HS").
Voici comment fonctionne l'outil : afin de savoir si un équipement du réseau est joignable et si oui, pour connaitre le temps qu'il faut à un paquet pour le joindre et revenir à la source, Ping envoie un message ICMP du type "Echo Request" (écho demandé) à l'équipement cible et attend une réponse en retour du type "Echo Response" (réponse à l'écho). L'outil mesure alors le nombre de paquets perdus et pour les paquets reçus le temps mis par ces derniers pour faire l'aller-retour .
Exemple d'utilisation de l'outil Ping en émettant les messages ICMP à destination du serveur web du MIT dont l'une des adresses IP est 18.7.22.69 :
localhost# ping 18.7.22.69
PING 18.7.22.69 (18.7.22.69) 56(84) bytes of data.
64 bytes from 18.7.22.69: icmp_seq=1 ttl=240 time=84.1 ms
64 bytes from 18.7.22.69: icmp_seq=2 ttl=240 time=83.6 ms
64 bytes from 18.7.22.69: icmp_seq=3 ttl=240 time=82.9 ms
64 bytes from 18.7.22.69: icmp_seq=4 ttl=240 time=83.2 ms
64 bytes from 18.7.22.69: icmp_seq=5 ttl=240 time=83.1 ms
--- 18.7.22.69 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4010ms
rtt min/avg/max/mdev = 82.926/83.421/84.157/0.427 ms
Le résultat nous montre que :
Par ailleurs, les temps d'aller-retour des messages ICMP sont les suivants :
temps aller-retour minimum : 82,926 millisecondes
temps aller-retour moyen : 83,421 millisecondes
temps aller-retour maximum : 84,157 millisecondes
déviation moyenne des temps d'aller-retour : 0,427 millisecondes
L'utilitaire "Traceroute" a été développé en décembre 1988 par Van Jacobson pour l'aide au diagnostic des problèmes réseau, tout comme l'outil Ping. Comme ce dernier le mot "Traceroute" est à présent aussi utilisé comme verbe (exemple: "il traceroute mon switch") mais aussi substantif (exemple: "ton traceroute montre que le routage n'est pas correct").
L'outil permet de lister l'ensemble des équipements situés sur le réseau et qui séparent la source et la cible. Ceci permet à l'utilisateur de connaitre sa route au travers du réseau et lui permet d'identifier les problématiques de routage ou de blocage de paquets jusqu'à un site.
Voici comment fonctionne l'outil : il envoie des paquets UDP (certaines versions utilisent des paquets TCP) en marquant le champ "TTL" de leur entête IP avec une valeur spécifique, puis attend les paquets ICMP de type "Time to live exceeded in transit" et "Destination unreachable" qui sont émis en retour.
En positionnant initialement la valeur TTL Time To Live de chaque bloc de paquets à "1", Traceroute force le premier équipement qui reçoit ses paquets à renvoyer un message ICMP Time to live exceeded in transit (puisque ce dernier décrémente la valeur en traitant le bloc). Puis en incrémentant successivement la valeur TTL à "2", "3", etc ..., il force le 2ème équipement, puis le 3ème, etc ... à renvoyer des messages ICMP.
Ainsi à chaque réception de message ICMP, il affiche l'équipement qui lui à répondu et de fil en aiguille reconstitue le chemin complet des paquets jusqu'à la cible. En mesurant le temps de chaque aller-retour, l'outil Traceroute peut également fournir à l'utilisateur des statistiques de latence des équipements. Si un équipement ne répond pas dans le temps imparti (appelé aussi "Time-Out"), l'outil affiche le caractère astérisque ("*") indiquant qu'il n'a pas de mesure.
Exemple d'utilisation de l'outil Traceroute en émettant les messages ICMP depuis l'Université Carnegie Mellon à destination du serveur web du MIT dont l'une des adresses IP est 18.7.22.69 :
traceroute to 18.7.22.69 (18.7.22.69), 30 hops max, 38 byte packets
1 POD-C-CYH-VL4.GW.CMU.NET (128.2.4.48) 0.355 ms 0.994 ms 0.252 ms
2 CORE255-VL907.GW.CMU.NET (128.2.255.186) 0.337 ms 0.247 ms 0.240 ms
3 POD-I-CYH-VL987.GW.CMU.NET (128.2.255.250) 44.844 ms 199.384 ms 5.931 ms
4 bar-cmu-ge-4-0-0-2.3rox.net (192.88.115.185) 0.547 ms 14.157 ms 2.545 ms
5 leviathan-bar-te0-0-0-1-508.3rox.net (192.88.115.85) 0.903 ms 0.655 ms 0.638 ms
6 wash-psc10G.layer3.nlr.net (192.88.115.165) 7.205 ms 6.688 ms 6.473 ms
7 newy-wash-98.layer3.nlr.net (216.24.186.22) 12.449 ms 12.419 ms 11.874 ms
8 216.24.184.102 (216.24.184.102) 11.745 ms 11.703 ms 11.641 ms
9 W92-RTR-1-BACKBONE.MIT.EDU (18.168.0.25) 19.069 ms 21.824 ms 18.624 ms
10 WEB.MIT.EDU (18.7.22.69) 17.754 ms 17.227 ms 17.147 ms
Le résultat nous montre que :
Par ailleurs, les propriétaires des équipements traversés sont :
La plupart des équipements de routage et de sécurité traitent les paquets ICMP en priorité puisqu'ils concernent les erreurs de transmission. Ceci peut être considéré comme un risque en terme de sécurité par certains administrateurs puisque l'envoi de paquets ICMP en trop grand nombre peut engorger un équipement. Il n'est donc pas rare de constater que certains équipements, même s'ils sont bien connectés au réseau, ne répondent pas aux messages ICMP de type Echo Request.
Pour des raisons de sécurité, certains équipements refusent aussi de transmettre à des équipements inconnus les messages ICMP attendus par traceroute. Bien que ce type de pratique soit assez critiqué, la volonté de ne pas dévoiler à n'importe qui la topologie de son réseau l'emporte bien souvent.
Agissant comme un protocole de niveau supérieur, ICMP est pourtant intégré au protocole IP. Les messages ICMP sont utilisés par les équipements pour la notification de tout erreur relatives à la gestion des flux de données. Par ailleurs, le protocole n'est pas sûr et ne garantit ni l'émission des messages, ni leur réception. L'implémentation de mécanismes garantissant les communications doit toujours être confiée aux protocoles des couches supérieures, tels que TCP.
Le protocole ICMP diffère de ses cousins TCP et UDP dans la mesure où ces derniers sont utilisés pour émettre et recevoir des paquets de données entre équipements finaux. ICMP assure quant à lui la gestion des messages concernant deux équipements proches, comme par exemple des routeurs.
Les paquets ICMP sont encapsulés dans des paquets IP avec un entête spécifique afin de permettre le renvoi du paquet vers l'équipement émetteur du paquet. Lorsqu'un équipement traite un paquet IP, il décrémente un champ de l'entête IP nommé TTL ("Time To Live"). Si la valeur du champ TTL équivaut à 0, un message ICMP spécifique du type "Time to live exceeded in transit" est alors renvoyé à l'équipement qui a émis le paquet lui indiquant que le paquet n'a pas pû être émis car sa durée de vie est expirée.
Il est assez peu commun qu'une application logicielle utilise le protocole ICMP puisqu'il est réservé au traitement des messages d'erreurs. Cependant, deux outils bien connus des administrateurs système et réseau ont été spécifiquement conçu dans ce cadre : il s'agit des outils nommés 'Ping" et "Traceroute" :
- Ping : utilisation des messages ICMP Echo Request et Echo Reply
- Traceroute : échange de paquets UDP et modification du champ TTL
L'utilitaire "Ping" a été développé en décembre 1983 par Mike Muuss, alors chercheur au Laboratoire de Recherche Balistique de l'armée américaine, pour l'aide au diagnostic des problèmes réseau. Mike Muss l'a nommé ainsi par analogie avec les impulsions sonores émises par les radars, dont le principe est similaire, l'onde radar étant ici remplacée par un paquet ICMP. Le mot "Ping" est à présent aussi utilisé comme verbe (exemple: "il ping mon routeur") mais aussi substantif (exemple: "ton ping montre que le serveur web est HS").
Voici comment fonctionne l'outil : afin de savoir si un équipement du réseau est joignable et si oui, pour connaitre le temps qu'il faut à un paquet pour le joindre et revenir à la source, Ping envoie un message ICMP du type "Echo Request" (écho demandé) à l'équipement cible et attend une réponse en retour du type "Echo Response" (réponse à l'écho). L'outil mesure alors le nombre de paquets perdus et pour les paquets reçus le temps mis par ces derniers pour faire l'aller-retour .
Exemple d'utilisation de l'outil Ping en émettant les messages ICMP à destination du serveur web du MIT dont l'une des adresses IP est 18.7.22.69 :
localhost# ping 18.7.22.69
PING 18.7.22.69 (18.7.22.69) 56(84) bytes of data.
64 bytes from 18.7.22.69: icmp_seq=1 ttl=240 time=84.1 ms
64 bytes from 18.7.22.69: icmp_seq=2 ttl=240 time=83.6 ms
64 bytes from 18.7.22.69: icmp_seq=3 ttl=240 time=82.9 ms
64 bytes from 18.7.22.69: icmp_seq=4 ttl=240 time=83.2 ms
64 bytes from 18.7.22.69: icmp_seq=5 ttl=240 time=83.1 ms
--- 18.7.22.69 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4010ms
rtt min/avg/max/mdev = 82.926/83.421/84.157/0.427 ms
Le résultat nous montre que :
- 5 paquets ont été émis et 5 paquets ont été reçus
- le pourcentage de paquets perdus est de 0%
- le temps total du test est de 4010 millisecondes
Par ailleurs, les temps d'aller-retour des messages ICMP sont les suivants :
temps aller-retour minimum : 82,926 millisecondes
temps aller-retour moyen : 83,421 millisecondes
temps aller-retour maximum : 84,157 millisecondes
déviation moyenne des temps d'aller-retour : 0,427 millisecondes
L'utilitaire "Traceroute" a été développé en décembre 1988 par Van Jacobson pour l'aide au diagnostic des problèmes réseau, tout comme l'outil Ping. Comme ce dernier le mot "Traceroute" est à présent aussi utilisé comme verbe (exemple: "il traceroute mon switch") mais aussi substantif (exemple: "ton traceroute montre que le routage n'est pas correct").
L'outil permet de lister l'ensemble des équipements situés sur le réseau et qui séparent la source et la cible. Ceci permet à l'utilisateur de connaitre sa route au travers du réseau et lui permet d'identifier les problématiques de routage ou de blocage de paquets jusqu'à un site.
Voici comment fonctionne l'outil : il envoie des paquets UDP (certaines versions utilisent des paquets TCP) en marquant le champ "TTL" de leur entête IP avec une valeur spécifique, puis attend les paquets ICMP de type "Time to live exceeded in transit" et "Destination unreachable" qui sont émis en retour.
En positionnant initialement la valeur TTL Time To Live de chaque bloc de paquets à "1", Traceroute force le premier équipement qui reçoit ses paquets à renvoyer un message ICMP Time to live exceeded in transit (puisque ce dernier décrémente la valeur en traitant le bloc). Puis en incrémentant successivement la valeur TTL à "2", "3", etc ..., il force le 2ème équipement, puis le 3ème, etc ... à renvoyer des messages ICMP.
Ainsi à chaque réception de message ICMP, il affiche l'équipement qui lui à répondu et de fil en aiguille reconstitue le chemin complet des paquets jusqu'à la cible. En mesurant le temps de chaque aller-retour, l'outil Traceroute peut également fournir à l'utilisateur des statistiques de latence des équipements. Si un équipement ne répond pas dans le temps imparti (appelé aussi "Time-Out"), l'outil affiche le caractère astérisque ("*") indiquant qu'il n'a pas de mesure.
Exemple d'utilisation de l'outil Traceroute en émettant les messages ICMP depuis l'Université Carnegie Mellon à destination du serveur web du MIT dont l'une des adresses IP est 18.7.22.69 :
traceroute to 18.7.22.69 (18.7.22.69), 30 hops max, 38 byte packets
1 POD-C-CYH-VL4.GW.CMU.NET (128.2.4.48) 0.355 ms 0.994 ms 0.252 ms
2 CORE255-VL907.GW.CMU.NET (128.2.255.186) 0.337 ms 0.247 ms 0.240 ms
3 POD-I-CYH-VL987.GW.CMU.NET (128.2.255.250) 44.844 ms 199.384 ms 5.931 ms
4 bar-cmu-ge-4-0-0-2.3rox.net (192.88.115.185) 0.547 ms 14.157 ms 2.545 ms
5 leviathan-bar-te0-0-0-1-508.3rox.net (192.88.115.85) 0.903 ms 0.655 ms 0.638 ms
6 wash-psc10G.layer3.nlr.net (192.88.115.165) 7.205 ms 6.688 ms 6.473 ms
7 newy-wash-98.layer3.nlr.net (216.24.186.22) 12.449 ms 12.419 ms 11.874 ms
8 216.24.184.102 (216.24.184.102) 11.745 ms 11.703 ms 11.641 ms
9 W92-RTR-1-BACKBONE.MIT.EDU (18.168.0.25) 19.069 ms 21.824 ms 18.624 ms
10 WEB.MIT.EDU (18.7.22.69) 17.754 ms 17.227 ms 17.147 ms
Le résultat nous montre que :
- 9 équipements séparent la source et la cible
- le temps aller-retour minimum est de 17,147 millisecondes
- le temps aller-retour moyen est de 17,227 millisecondes
- le temps aller-retour maximum est de 17,754 millisecondes
Par ailleurs, les propriétaires des équipements traversés sont :
- l'Université Carnegie Mellon (cmu.net)
- l'opérateur Three Rivers Optical Exchange (3rox.net)
- l'opérateur National LambdaRail (nlr.net)
- l'Institut Technologique du Massachusetts (mit.edu)
La plupart des équipements de routage et de sécurité traitent les paquets ICMP en priorité puisqu'ils concernent les erreurs de transmission. Ceci peut être considéré comme un risque en terme de sécurité par certains administrateurs puisque l'envoi de paquets ICMP en trop grand nombre peut engorger un équipement. Il n'est donc pas rare de constater que certains équipements, même s'ils sont bien connectés au réseau, ne répondent pas aux messages ICMP de type Echo Request.
Pour des raisons de sécurité, certains équipements refusent aussi de transmettre à des équipements inconnus les messages ICMP attendus par traceroute. Bien que ce type de pratique soit assez critiqué, la volonté de ne pas dévoiler à n'importe qui la topologie de son réseau l'emporte bien souvent.