Probablement le plus utilisé, ICMP dispose de deux types de message:

• 8 Demande d'écho (ping request);
• 0 Envoi de l'écho (ping reply).

Largement utilisé pour savoir si la cible est présente et accessoirement, pour connaître le temps mis pour la joindre.

La commande ping est utilisable aussi bien en IPv4 qu'en IPv6.

Bien entendu, l'application (ping) qui utilise directement ce message 8 va lancer le ping et attendre «un certain temps» avant de décider qu'il n'y a pas de réponse. La commande ping de GNU/Linux propose quelques paramètres fondamentalement utiles:

• -c nombre indique le nombre de ping request à envoyer. Si ce paramètre n'est pas fourni, la commande envoie des ping request jusqu'à extinction du processus (Ctrl+C)
• -n Pour éviter que le système cherche à faire du RDNS (recherche d'un nom à partir d'une adresse) Non seulement cette résolution inverse n'aboutit pas systématiquement, mais encore lorsqu'elle aboutit, rien ne dit que la réponse est vraie. L'étude détaillée de DNS expliquera pourquoi.
• -4 pour forcer l'emploi d'IPv4 sur une machine disposant de la double configuration;
• -6 même chose, mais pour IPv6.

Il y en a encore beaucoup d'autres, moins souvent utilisées. Voir le «man ping» pour les afficher toutes.

les types ICMP utilisée par ping sont exploitables aussi bien en IPv4 qu'en IPv6.

ping -c4 www.debian.org

PING www.debian.org(static-mirror-grnet-01.debian.org (2001:648:2ffc:deb:216:61ff:fe2b:6138)) 56 data bytes
64 bytes from static-mirror-grnet-01.debian.org (2001:648:2ffc:deb:216:61ff:fe2b:6138): icmp_seq=1 ttl=42 time=65.6 ms
64 bytes from static-mirror-grnet-01.debian.org (2001:648:2ffc:deb:216:61ff:fe2b:6138): icmp_seq=2 ttl=42 time=65.1 ms
64 bytes from static-mirror-grnet-01.debian.org (2001:648:2ffc:deb:216:61ff:fe2b:6138): icmp_seq=3 ttl=42 time=65.6 ms
64 bytes from static-mirror-grnet-01.Debian.org (2001:648:2ffc:deb:216:61ff:fe2b:6138): icmp_seq=4 ttl=42 time=65.4 ms

--- www.debian.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 65.106/65.421/65.638/0.203 ms

D'où l'utilité de certains paramètres. La résolution RDNS a été appliquée à des adresses IPv6. Et ce RDNS a donné un autre URI que www.debian.org. La réponse, encore expliquée avec l'étude détaillée de DNS est que www.debian.org n'est pas un nom de nœud mais un «pseudo» qui peut pointer vers différents nœuds, mais qui ont la particularité d'être des copies parfaites.

Reprenons la manip. autrement:

ping -c2 -n -4 www.debian.org

PING  (130.89.148.77) 56(84) bytes of data.
64 bytes from 130.89.148.77: icmp_seq=1 ttl=54 time=33.0 ms
64 bytes from 130.89.148.77: icmp_seq=2 ttl=54 time=29.7 ms

---  ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 29.683/31.323/32.964/1.640 ms

Ici -c 2 pour n'envoyer que 2 requêtes, -n pour éviter le RDNS et -4 pour forcer IPv4. L'expérience permet de déduire que dans le cas d'une double configuration IPv4 et IPv6, c'est IPv6 qui est utilisé par défaut, IPv4 ne venant qu'en cas d'échec IPv6 ou si le protocole a été explicitement demandé.

La curiosité n'est pas toujours un défaut. Wireshark était là par hasard, et il a capturé ceci:

No.Time    Source         Destination     Protocol Length Info
 1 0.00    192.168.60.47  130.89.148.77   ICMP     98     Echo (ping) request  id=0x5037, seq=1/256, ttl=64 (reply in 2)
 2 0.03    130.89.148.77  192.168.60.47   ICMP     98     Echo (ping) reply    id=0x5037, seq=1/256, ttl=54 (request in 1)
 3 1.00    192.168.60.47  130.89.148.77   ICMP     98     Echo (ping) request  id=0x5037, seq=2/512, ttl=64 (reply in 4)
 4 1.03    130.89.148.77  192.168.60.47   ICMP     98     Echo (ping) reply    id=0x5037, seq=2/512, ttl=54 (request in 3)

Regardons le détail de la couche ICMP de la première trame:

Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0
    Checksum: 0x5bd2
    Identifier (BE): 20535 (0x5037)
    Identifier (LE): 14160 (0x3750)
    Sequence Number (BE): 1 (0x0001)
    Sequence Number (LE): 256 (0x0100)
    Timestamp from icmp data: Mar  6, 2025 17:43:01.000000000 CET
    Data (48 bytes)
       0000  21 ea 0c 00 00 00 00 00 10 11 12 13 14 15 16 17   !...............
       0010  18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27   ........ !"#$%&'
       0020  28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37   ()*+,-./01234567

Nous retrouvons le type 8 avec un code 0 qui n'a pas d'importance particulière, le type 8 ne dispose pas d'autre code. Il y a 48 octets de données… Voyons la réponse:

Internet Control Message Protocol
    Type: 0 (Echo (ping) reply)
    Code: 0
    Checksum: 0x63d2
    Identifier (BE): 20535 (0x5037)
    Identifier (LE): 14160 (0x3750)
    Sequence Number (BE): 1 (0x0001)
    Sequence Number (LE): 256 (0x0100)
    Timestamp from icmp data: Mar  6, 2025 17:43:01.000000000 CET
    Data (48 bytes)
        0000  21 ea 0c 00 00 00 00 00 10 11 12 13 14 15 16 17   !...............
        0010  18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27   ........ !"#$%&'
        0020  28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37   ()*+,-./01234567

Type 0 comme prévu, là encore, le code = 0 mais n'a pas de signification particulière. Le «timestamp» et les «data» sont les mêmes que dans le ping request. les 48 octets de data + les 8 octets de timestamp = 56, ce que l'on retrouve dans le «man ping» à la description du paramètre -s:

-s taille_paquet : Spécifier le nombre d'octets de données à envoyer. Le nombre par défaut est 56, ce qui se traduit en 64 octets de données ICMP quand ils sont combinés avec les 8 octets de données de l'en-tête ICMP.

Ces 56 octets doivent être identiques dans la requête et sa réponse, mais nous pouvons aussi en déduire que la taille de la charge peut être modifiée et donc éventuellement devenir explosive…

Mais cette option ne servira pas dans la plupart des cas.