Il y a une très grande variété de raisons pour qu'un destinataire soit inaccessible. Il peut:

• exister mais ne pas avoir le port concerné ouvert;
• ne pas exister du tout;
• exister, mais inaccessible à cause d'un défaut de routage;
• exister mais refuser le dialogue;
• le réseau, tout simplement, n'est pas accessible;
• etc.

Dans ces cas de figure, le type ICMP = 3, c'est le code qui va définir la nature de l'échec. Voici quelques exemples:

Premier exemple où 192.168.60.252 cherche à faire un ping sur 192.168.65.1. C'est une adresse privée, pas routable sur le net et n'existant pas sur le réseau local. Rappelons que 192.168.60.0/24 dispose de la passerelle par défaut 192.168.60.254. Voici (en résumé) ce que capture Wireshark sur l'action:

No.   Source                Destination           Protocol Info
 1    192.168.60.252        192.168.65.1          ICMP     Echo (ping) request
 2    192.168.60.254        192.168.60.252        ICMP     Destination unreachable

Internet Control Message Protocol
    Type: 3 (Destination unreachable)
    Code: 1 (Host unreachable)

C'est la passerelle qui répond que la destination n'est pas accessible, ce que l'on savait compte tenu de ce qui a été dit plus haut. Ici nous avons le type 3 avec le code 1.

Cependant, toutes ces erreurs ne seront pas forcément signalées par ICMP. Par exemple si l'on cherche a établir une connexion TCP sur le port 80 d'un nœud qui n'a pas ouvert ce port, c'est TCP qui signalera le problème avec un [RST-ACK] en réponse au [SYN] envoyé par le client.

Une station du réseau local 192.168.60.0/24 cherche à joindre un serveur HTTP sur 192.168.60.252, mais il n'y a pas de serveur HTTP ouvrant le port 80 sur ce nœud. Si un client web cherche à joindre http://192.168.60.252, il recevra, certes, un message d'erreur. Cependant wireshark voit passer ceci:

No. Source             Destination      Protocol  Info
 1  192.168.60.47      192.168.60.252   TCP       56196 → 80 [SYN]
 2  192.168.60.252     192.168.60.47    TCP       80 → 56196 [RST, ACK]

Pas besoin de développer davantage, tout se passe par TCP.

Si l'on y ajoute maintenant un un pare-feu¹⁾ qui rejette explicitement les connexions sur le port 80. Voici ce que voit (en résumé) Wireshark sur l'action:

No.  Source         Destination           Protocol  Info
  2  192.168.60.47  192.168.60.252        TCP       47882 → 80 [SYN]

Internet Protocol Version 4, Src: 192.168.60.47, Dst: 192.168.60.252

Transmission Control Protocol, Src Port: 47882, Dst Port: 80, Seq: 0, Len: 0
    Source Port: 47882
    Destination Port: 80
 
No.  Source          Destination           Protocol Info
  3  192.168.60.252  192.168.60.47         ICMP     Destination unreachable (Port unreachable)


Internet Protocol Version 4, Src: 192.168.60.252, Dst: 192.168.60.47
 
Internet Control Message Protocol
    Type: 3 (Destination unreachable)
    Code: 3 (Port unreachable)

    Transmission Control Protocol, Src Port: 47882, Dst Port: 80, Seq: 1180073534

Ici nous avons toujours le type 3, mais avec le code 3.

Sans développer le fonctionnement de la commande traceroute, voyons ce que Wireshark capture sur le premier «hop» d'un traceroute www.debian.org:

No.  Source           Destination           Protocol Info
  4  192.168.60.252   130.89.148.77         UDP      39659 → 33434 Len=32
 11  192.168.60.254   192.168.60.252        ICMP     Time-to-live exceeded 

La source (192.168.60.252)envoie un datagramme (UDP) sur la cible 130.89.148.77 et la passerelle par défaut (192.168.60.254) répond avec un message ICMP Time-to-live exceeded

???

Dans le datagramme de départ il y a au niveau IP:

Internet Protocol Version 4, Src: 192.168.60.252, Dst: 130.89.148.77
    ...
    Time to Live: 1
    ...
    Protocol: UDP (17)

Rappelons-nous ce champ «Time-to-mive» dans les paquets IP. Ici le pauvre, il n'a qu'un point de vie . Nous avions dit que la première chose que faisait un routeur, c'était de décrémenter ce TTL quand le paquet arrivait et de prévenir la source si ce TTL devenait nul.

C'est ce qu'il se passe ici sur la première passerelle rencontrée, c'est-à-dire notre passerelle par défaut 192.168.60.254. Observons le détail ICMP de la réponse:

Internet Control Message Protocol
    Type: 11 (Time-to-live exceeded)
    Code: 0 (Time to live exceeded in transit)
    ...
    Internet Protocol Version 4, Src: 192.168.60.252, Dst: 130.89.148.77
    ...

Notre passerelle par défaut a donc fait son travail, elle a décrémenté le TTL du paquet UDP, qui est tombé à 0 et donc la passerelle nous en a informé avec le message ICMP de type 11 et de code 0: «Temps de vie du datagramme dépassé».

Voilà le principe de base du tracé de route. Le coup suivant, la source va envoyer encore un datagramme UDP vers la cible, mais avec un TTL de 2, etc.