Difference between revisions of "Format du message ICMPv6"

From Livre IPv6
(Undo revision 10614 by Panelli (talk))
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
{{Suivi|Format du paquet IPv6|Format du paquet IPv6|Exemples de paquets|Exemples de paquets}}
 +
 
__TOC__
 
__TOC__
−
Le protocole de contrôle d'IP a été revu. Dans IPv4, ICMP (Internet Message Control Protocol) sert à la détection d'erreurs (par exemple : équipement inaccessible, durée de vie expirée,...), au test (par exemple ping), à la configuration automatique des équipements (redirection ICMP, découverte des routeurs). Ces trois fonctions ont été mieux définies dans IPv6. De plus ICMPv6 (RFC 2463) intègre les fonctions de gestion des groupes de multicast (MLD : Multicast Listener Discovery) qui sont effectuées par le protocole IGMP (Internet Group Message Protocol) dans IPv4. ICMPv6 reprend aussi les fonctions du protocole ARP utilisé par IPv4.
+
Le protocole de contrôle d'IP a été revu. Dans IPv4, ICMP (Internet Message Control Protocol) sert à la détection d'erreurs (par exemple : équipement inaccessible, durée de vie expirée,...), au test (par exemple ping), à la configuration automatique des équipements (redirection ICMP, découverte des routeurs). Ces trois fonctions ont été mieux définies dans IPv6. De plus ICMPv6 (RFC 4443) intègre les fonctions de gestion des groupes de multicast (MLD : Multicast Listener Discovery) qui sont effectuées par le protocole IGMP (Internet Group Message Protocol) dans IPv4. ICMPv6 reprend aussi les fonctions du protocole ARP utilisé par IPv4.
  
 
<tikz title="Format du message ICMPv6">
 
<tikz title="Format du message ICMPv6">
Line 21: Line 23:
 
* Le champ <tt>checksum</tt> permet de vérifier l'intégrité du paquet ICMP. Ce champ est calculé avec le pseudo-en-tête décrit au chapitre [[Checksum au niveau transport]].
 
* Le champ <tt>checksum</tt> permet de vérifier l'intégrité du paquet ICMP. Ce champ est calculé avec le pseudo-en-tête décrit au chapitre [[Checksum au niveau transport]].
  
−
{{HorsTexte|Pourquoi ne pas filtrer ICMPv6|Supposons que le MTU entre un client et un serveur soit de 1480 octets à cause d'un tunnel IPv6 dans IPv4 et qu'un serveur filtre les messages ICMPv6 (en particulier Paquet trop grand). Le client et le serveur vont échanger des petits paquets pour ouvrir la connexion TCP (SYN, SYN ACK, ACK), puis le client va envoyer une commande HTTP courte (GET /). Le serveur va répondre en envoyant une page complète, si le paquet est trop grand, le routeur va rejeter le paquet et envoyer au serveur un message indiquant que le paquet et trop grand. Si le pare-feux du serveur le filtre, il ne pourra jamais adapter la taille du paquet. On se trouve dans une situation où certains paquets passent (ouverture de connexion, ping, session SSH,...) et d'autres sont bloquées}}  
+
{{HorsTexte|Pourquoi ne pas filtrer ICMPv6|Supposons que le MTU entre un client et un serveur soit de 1480 octets à cause d'un tunnel IPv6 dans IPv4 et qu'un serveur filtre les messages ICMPv6 (en particulier Paquet trop grand). Le client et le serveur vont échanger des petits paquets pour ouvrir la connexion TCP (SYN, SYN ACK, ACK), puis le client va envoyer une commande HTTP courte (GET /). Le serveur va répondre en envoyant une page complète, si le paquet est trop grand, le routeur va rejeter le paquet et envoyer au serveur un message indiquant que le paquet et trop grand. Si le pare-feux du serveur le filtre, le serveur ne pourra jamais adapter la taille du paquet. On se trouve dans une situation où certains paquets passent (ouvertures de connexion, ping, sessions SSH,...) et d'autres sont bloquées.}}  
  
 
Les messages ICMPv6 de compte rendu d'erreur contiennent dans la partie données le paquet IPv6 ayant provoqué l'erreur. Pour éviter des problèmes de fragmentation puisqu'il est difficilement envisageable de mettre en œuvre la découverte du MTU, la longueur du message ICMPv6 est limitée à 1 280 octets et par conséquent le contenu du paquet IPv6 peut être tronqué.
 
Les messages ICMPv6 de compte rendu d'erreur contiennent dans la partie données le paquet IPv6 ayant provoqué l'erreur. Pour éviter des problèmes de fragmentation puisqu'il est difficilement envisageable de mettre en œuvre la découverte du MTU, la longueur du message ICMPv6 est limitée à 1 280 octets et par conséquent le contenu du paquet IPv6 peut être tronqué.
  
−
Contrairement à une pratique couramment répandue en IPv4, il ne faut jamais filtrer les messages ICMPv6 (en particulier Paquet trop grand) car cela peut avoir des conséquences néfaste sur le bon fonctionnement du réseau.
+
Contrairement à une pratique couramment répandue en IPv4, il ne faut jamais filtrer les messages ICMPv6 (en particulier Paquet trop grand) car cela peut avoir des conséquences néfastes sur le bon fonctionnement du réseau.
  
  
Line 35: Line 37:
 
== <div id="inaccessible">Destination inaccessible</div> ==
 
== <div id="inaccessible">Destination inaccessible</div> ==
  
−
[[image:Fig4-12.png|thumb|right|300px|Figure 4-12 ''Format d'un message ICMP Destination inaccessible'']]
+
<tikz title="Format d'un message ICMP Destination inaccessible">
 +
\clip (0.2, 3.5) rectangle (11.1,7.1);
 +
%\draw[help lines] (0,0) grid (11,6);
 +
 
 +
\draw (0.5, 6.5) node  [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
 +
 +
\draw (0.5, 6) node (context) [right, shade,  draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type = 1}};
 +
\draw (2.9, 6) node (context) [right, shade,  draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code}};
 +
\draw (5.3, 6) node (context) [right, shade,  draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
 +
\draw (0.5, 5.5) node (context) [right, shade,  draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Unused}};
 +
 +
 +
\draw (0.5, 4.25) node (context) [right, shade,  draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Packet which generated error \\
 +
(with MTU constraint)}};
 +
 
 +
 
 +
</tikz>
  
 
Ce message est émis par un routeur intermédiaire quand le paquet ne peut pas être transmis parce que soit :
 
Ce message est émis par un routeur intermédiaire quand le paquet ne peut pas être transmis parce que soit :
Line 43: Line 61:
 
* l'adresse destination ne peut être atteinte avec l'adresse source fournie, par exemple si le message est adressé à un destinataire hors du lien, l'adresse source ne doit pas être une adresse lien-local (code = 2) ;
 
* l'adresse destination ne peut être atteinte avec l'adresse source fournie, par exemple si le message est adressé à un destinataire hors du lien, l'adresse source ne doit pas être une adresse lien-local (code = 2) ;
 
* toute autre raison comme par exemple la tentative de routage d'une adresse locale au lien (code = 3) ;
 
* toute autre raison comme par exemple la tentative de routage d'une adresse locale au lien (code = 3) ;
−
* le destinataire peut aussi émettre un message ICMPv6 de ce type quand le port destination contenu dans le paquet n'est pas affecté à une application (code = 4).
+
* le destinataire peut aussi émettre un message ICMPv6 de ce type quand le port destination contenu dans le paquet n'est pas affecté à une application (code = 4) ;
 +
* le paquet a été rejeté à cause de son adresse source (code = 5) ;
 +
* la route vers la destination conduit a un rejet du paquet (code = 6).
  
 
== <div id="grand">Paquet trop grand</div> ==
 
== <div id="grand">Paquet trop grand</div> ==
  
−
[[image:Fig4-13.png|thumb|right|300px|Figure 4-13 ''Format d'un message ICMP Paquet trop grand'']]
+
<tikz title="Format d'un message ICMP Paquet trop grand">
 +
\clip (0.2, 3.5) rectangle (11.1,7.1);
 +
%\draw[help lines] (0,0) grid (11,6);
 +
 
 +
\draw (0.5, 6.5) node  [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
 +
 +
\draw (0.5, 6) node (context) [right, shade,  draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type = 2}};
 +
\draw (2.9, 6) node (context) [right, shade,  draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code = 0}};
 +
\draw (5.3, 6) node (context) [right, shade,  draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
 +
\draw (0.5, 5.5) node (context) [right, shade,  draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{MTU}};
 +
 +
 +
\draw (0.5, 4.25) node (context) [right, shade,  draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Packet which generated error \\
 +
(with MTU constraint)}};
 +
 
 +
</tikz>
  
 
Ce message ICMPv6 est utilisé par le protocole de découverte du MTU pour trouver la taille optimale des paquets IPv6 afin qu'ils puissent traverser les routeurs. Ce message contient la taille du MTU acceptée par le routeur pour que la source puisse efficacement adapter la taille des données. Ce champ manquait cruellement dans les spécifications initiales de IPv4, ce qui compliquait la découverte de la taille maximale des paquets utilisables sur l'ensemble du chemin (cf. [[Mécanisme de découverte du PMTU|découverte du PMTU]] (RFC 1981)). Pour IPv4, le RFC 1191 proposait déjà une modification du comportement des routeurs pour y inclure cette information.
 
Ce message ICMPv6 est utilisé par le protocole de découverte du MTU pour trouver la taille optimale des paquets IPv6 afin qu'ils puissent traverser les routeurs. Ce message contient la taille du MTU acceptée par le routeur pour que la source puisse efficacement adapter la taille des données. Ce champ manquait cruellement dans les spécifications initiales de IPv4, ce qui compliquait la découverte de la taille maximale des paquets utilisables sur l'ensemble du chemin (cf. [[Mécanisme de découverte du PMTU|découverte du PMTU]] (RFC 1981)). Pour IPv4, le RFC 1191 proposait déjà une modification du comportement des routeurs pour y inclure cette information.
Line 53: Line 88:
 
== <div id="depasse">Temps dépassé</div> ==
 
== <div id="depasse">Temps dépassé</div> ==
  
−
[[image:Fig4-14.png|thumb|right|300px|Figure 4-14 ''Format d'un message ICMP Temps dépassé'']]
+
<tikz title="Format d'un message ICMP Temps dépassé">
 +
\clip (0.2, 3.5) rectangle (11.1,7.1);
 +
%\draw[help lines] (0,0) grid (11,6);
  
 +
\draw (0.5, 6.5) node  [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
 +
 +
\draw (0.5, 6) node (context) [right, shade,  draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type = 3}};
 +
\draw (2.9, 6) node (context) [right, shade,  draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code }};
 +
\draw (5.3, 6) node (context) [right, shade,  draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
 +
\draw (0.5, 5.5) node (context) [right, shade,  draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Unused}};
 +
 +
 +
\draw (0.5, 4.25) node (context) [right, shade,  draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Packet which generated error \\
 +
(with MTU constraint)}};
 +
 +
 +
</tikz>
  
 
Ce message indique que le paquet a été rejeté par le routeur :
 
Ce message indique que le paquet a été rejeté par le routeur :
Line 66: Line 116:
 
== <div id="parametre">Erreur de paramètre</div> ==
 
== <div id="parametre">Erreur de paramètre</div> ==
  
−
[[image:Fig4-15.png|thumb|right|300px|Figure 4-15 ''Format d'un message ICMP Erreur de paramètre'']]
 
  
 +
<tikz title="Format d'un message ICMP Erreur de paramètre">
 +
\clip (0.2, 3.5) rectangle (11.1,7.1);
 +
%\draw[help lines] (0,0) grid (11,6);
 +
 +
\draw (0.5, 6.5) node  [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
 +
 +
\draw (0.5, 6) node (context) [right, shade,  draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type = 4}};
 +
\draw (2.9, 6) node (context) [right, shade,  draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code }};
 +
\draw (5.3, 6) node (context) [right, shade,  draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
 +
\draw (0.5, 5.5) node (context) [right, shade,  draw, minimum height=0.5cm, minimum width=9.6cm]{\tiny{Pointer}};
 +
 +
 +
\draw (0.5, 4.25) node (context) [right, shade,  draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Packet which generated error \\
 +
(with MTU constraint)}};
 +
 +
</tikz>
  
 
Ce message est émis par un nœud ayant détecté une erreur de syntaxe dans l'en-tête du paquet IP ou des extensions. Le champ code révèle la cause de l'erreur :
 
Ce message est émis par un nœud ayant détecté une erreur de syntaxe dans l'en-tête du paquet IP ou des extensions. Le champ code révèle la cause de l'erreur :
Line 79: Line 144:
 
== <div id="echo">Demande et réponse d'écho</div> ==
 
== <div id="echo">Demande et réponse d'écho</div> ==
  
−
[[image:Fig4-16.png|thumb|right|300px|Figure 4-16 ''Format d'un message ICMP Demande et réponse d'écho'']]
+
<tikz title="Format d'un message ICMP Demande et réponse d'écho">
 +
\draw (0.5, 6.5) node  [right] {\tiny{\tt{0..................7...................15...................23....................31}}};
 +
 +
\draw (0.5, 6) node (context) [right, shade, top color=blue,  draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Type = 128/129}};
 +
\draw (2.9, 6) node (context) [right, shade,  top color=blue, draw, minimum height=0.5cm, minimum width=2.4cm]{\tiny{Code =0 }};
 +
\draw (5.3, 6) node (context) [right, shade,  top color=blue,  draw, minimum height=0.5cm, minimum width=4.8cm] {\tiny{Checksum}};
 +
\draw (0.5, 5.5) node (context) [right, shade,  top color=blue,  draw, minimum height=0.5cm, minimum width=4.8cm]{\tiny{Identifier}};
 +
\draw (5.3, 5.5) node (context) [right, shade,  top color=blue,  draw, minimum height=0.5cm, minimum width=4.8cm]{\tiny{Sequence Number}};
 +
 
 +
 +
\draw (0.5, 4.25) node (context) [right, shade,  top color=blue, draw, minimum height=2cm, minimum width=9.6cm, text width=5cm, text centered] {\tiny{Data}};
 +
</tikz>
  
 
Ces deux messages servent en particulier à la commande ping permettant de tester l'accessibilité d'une machine. Le principe de fonctionnement est le même que pour IPv4, une requête (type 128) est envoyée vers l'équipement dont on veut tester le fonctionnement, celui-ci répond par le message réponse d'écho (type 129). Le champ identificateur permet de distinguer les réponses dans le cas où plusieurs commandes ping seraient lancées simultanément sur la machine. Le champ numéro de séquence permet d'associer la réponse à une requête pour mesurer le temps d'aller et retour dans le cas où les demandes sont émises en continu et que le délai de propagation est élevé. Le champ données permet d'augmenter la taille du message pour les mesures.
 
Ces deux messages servent en particulier à la commande ping permettant de tester l'accessibilité d'une machine. Le principe de fonctionnement est le même que pour IPv4, une requête (type 128) est envoyée vers l'équipement dont on veut tester le fonctionnement, celui-ci répond par le message réponse d'écho (type 129). Le champ identificateur permet de distinguer les réponses dans le cas où plusieurs commandes ping seraient lancées simultanément sur la machine. Le champ numéro de séquence permet d'associer la réponse à une requête pour mesurer le temps d'aller et retour dans le cas où les demandes sont émises en continu et que le délai de propagation est élevé. Le champ données permet d'augmenter la taille du message pour les mesures.
  
 
Le chapitre sur l'API, [[mini-ping]], donne un exemple de programmation utilisant ces messages ICMPv6.
 
Le chapitre sur l'API, [[mini-ping]], donne un exemple de programmation utilisant ces messages ICMPv6.
 +
{{Suivi|Format du paquet IPv6|Format du paquet IPv6|Exemples de paquets|Exemples de paquets}}

Latest revision as of 06:48, 14 March 2016

Format du paquet IPv6 Table des matières Exemples de paquets

Le protocole de contrôle d'IP a été revu. Dans IPv4, ICMP (Internet Message Control Protocol) sert à la détection d'erreurs (par exemple : équipement inaccessible, durée de vie expirée,...), au test (par exemple ping), à la configuration automatique des équipements (redirection ICMP, découverte des routeurs). Ces trois fonctions ont été mieux définies dans IPv6. De plus ICMPv6 (RFC 4443) intègre les fonctions de gestion des groupes de multicast (MLD : Multicast Listener Discovery) qui sont effectuées par le protocole IGMP (Internet Group Message Protocol) dans IPv4. ICMPv6 reprend aussi les fonctions du protocole ARP utilisé par IPv4.

Format du message ICMPv6
Figure : Format du message ICMPv6

Le protocole se voit attribuer le numéro 58. Le format générique des paquets ICMPv6 est donné figure Format générique d'un message ICMP :

  • Le champ type (voir tableau Valeurs des champs type et code d'ICMPv6) code la nature du message ICMPv6. Contrairement à IPv4 où la numérotation ne suivait aucune logique, les valeurs inférieures à 127 sont réservées aux messages d'erreur. Les autres valeurs réservées aux messages d'information, parmi lesquels se trouvent ceux utilisés par le protocole découverte des voisins (neighbor discovery) pour la configuration automatique des équipements.
  • Le champ code précise la cause du message ICMPv6.
  • Le champ checksum permet de vérifier l'intégrité du paquet ICMP. Ce champ est calculé avec le pseudo-en-tête décrit au chapitre Checksum au niveau transport.

Pourquoi ne pas filtrer ICMPv6

Supposons que le MTU entre un client et un serveur soit de 1480 octets à cause d'un tunnel IPv6 dans IPv4 et qu'un serveur filtre les messages ICMPv6 (en particulier Paquet trop grand). Le client et le serveur vont échanger des petits paquets pour ouvrir la connexion TCP (SYN, SYN ACK, ACK), puis le client va envoyer une commande HTTP courte (GET /). Le serveur va répondre en envoyant une page complète, si le paquet est trop grand, le routeur va rejeter le paquet et envoyer au serveur un message indiquant que le paquet et trop grand. Si le pare-feux du serveur le filtre, le serveur ne pourra jamais adapter la taille du paquet. On se trouve dans une situation où certains paquets passent (ouvertures de connexion, ping, sessions SSH,...) et d'autres sont bloquées.

Les messages ICMPv6 de compte rendu d'erreur contiennent dans la partie données le paquet IPv6 ayant provoqué l'erreur. Pour éviter des problèmes de fragmentation puisqu'il est difficilement envisageable de mettre en œuvre la découverte du MTU, la longueur du message ICMPv6 est limitée à 1 280 octets et par conséquent le contenu du paquet IPv6 peut être tronqué.

Contrairement à une pratique couramment répandue en IPv4, il ne faut jamais filtrer les messages ICMPv6 (en particulier Paquet trop grand) car cela peut avoir des conséquences néfastes sur le bon fonctionnement du réseau.


Valeurs des champs type et code d'ICMPv6
type code nature
Gestion des erreurs
1 Destination inaccessible :
0 * aucune route vers la destination
1 * la communication avec la destination est administrativement interdite
2 * hors portée de l'adresse source
3 * l'adresse est inaccessible
4 * le numéro de port est inaccessible
5 * l'adresse source est filtrée par un firewall
6 * l'adresse destination est rejetée
2
3 Temps dépassé :
0 * limite du nombre de sauts atteinte
1 * temps de réassemblage dépassé
4 Erreur de paramètre :
0 * champ d'en-tête erroné
1 * champ d'en-tête suivant non reconnu
2 * option non reconnue
Information
128 Demande d'écho
129 Réponse d'écho
Gestion des groupes multicast (MLD, RFC 2710)
130 Requête d'abonnement
131 Rapport d'abonnement
132 Fin d'abonnement
Découverte de voisins (RFC 2461)
133 Sollicitation du routeur
134 Annonce du routeur
135 Sollicitation d'un voisin
136 Annonce d'un voisin
137 Redirection
Renumérotation des routeurs (expérimental, RFC 2894)
138
Renumérotation des routeurs :
0 * Commande
1 * Résultat
255 * Remise à zéro du numéro de séquence
Recherche d'information sur un noeud (expérimental)
139 Demande d'information
140 Réponse
Découverte de voisins inverse (RFC 3122)
141 Sollicitation
142 Annonce
Gestion des groupes multicast (MLDv2, RFC 3810)
143 Rapport d'abonnement MLDv2
Mobilité (RFC 3775)
144 Découverte d'agent mère (requête)
145 Découverte d'agent mère (réponse)
146 Sollicitation de préfixe mobile
147 Annonce de préfixe mobile
Découverte de voisins sécurisée (SEND, RFC 3971)
148 Sollicitation de chemin de certification
149 Annonce de chemin de certification
Mobilité (expérimental)
150 Protocoles de mobilité expérimentaux, tels que Seamoby


Destination inaccessible

Format d'un message ICMP Destination inaccessible
Figure : Format d'un message ICMP Destination inaccessible

Ce message est émis par un routeur intermédiaire quand le paquet ne peut pas être transmis parce que soit :

  • le routeur ne trouve pas dans ses tables la route vers la destination (code = 0) ;
  • le franchissement d'un équipement de type firewall est interdit ("raison administrative", code = 1) ;
  • l'adresse destination ne peut être atteinte avec l'adresse source fournie, par exemple si le message est adressé à un destinataire hors du lien, l'adresse source ne doit pas être une adresse lien-local (code = 2) ;
  • toute autre raison comme par exemple la tentative de routage d'une adresse locale au lien (code = 3) ;
  • le destinataire peut aussi émettre un message ICMPv6 de ce type quand le port destination contenu dans le paquet n'est pas affecté à une application (code = 4) ;
  • le paquet a été rejeté à cause de son adresse source (code = 5) ;
  • la route vers la destination conduit a un rejet du paquet (code = 6).

Paquet trop grand

Format d'un message ICMP Paquet trop grand
Figure : Format d'un message ICMP Paquet trop grand

Ce message ICMPv6 est utilisé par le protocole de découverte du MTU pour trouver la taille optimale des paquets IPv6 afin qu'ils puissent traverser les routeurs. Ce message contient la taille du MTU acceptée par le routeur pour que la source puisse efficacement adapter la taille des données. Ce champ manquait cruellement dans les spécifications initiales de IPv4, ce qui compliquait la découverte de la taille maximale des paquets utilisables sur l'ensemble du chemin (cf. découverte du PMTU (RFC 1981)). Pour IPv4, le RFC 1191 proposait déjà une modification du comportement des routeurs pour y inclure cette information.

Temps dépassé

Format d'un message ICMP Temps dépassé
Figure : Format d'un message ICMP Temps dépassé

Ce message indique que le paquet a été rejeté par le routeur :

  • soit parce que le champ nombre de sauts a atteint 0 (code = 0) ;
  • soit qu'un fragment s'est perdu et le temps alloué au réassemblage a été dépassé (code = 1).


Ce message sert aussi à la commande traceroute pour déterminer le chemin pris par les paquets.

Erreur de paramètre

Format d'un message ICMP Erreur de paramètre
Figure : Format d'un message ICMP Erreur de paramètre

Ce message est émis par un nœud ayant détecté une erreur de syntaxe dans l'en-tête du paquet IP ou des extensions. Le champ code révèle la cause de l'erreur :

  • la syntaxe de l'en-tête n'est pas correcte (code = 0) ;
  • le numéro en-tête suivant n'est pas reconnu (code = 1) ;
  • une option de l'extension (par exemple proche-en-proche ou destination) n'est pas reconnue et le codage des deux bits de poids fort oblige à rejeter le paquet (code = 2).

Le champ pointeur indique l'octet où l'erreur est survenue dans le paquet retourné.

Demande et réponse d'écho

Format d'un message ICMP Demande et réponse d'écho
Figure : Format d'un message ICMP Demande et réponse d'écho

Ces deux messages servent en particulier à la commande ping permettant de tester l'accessibilité d'une machine. Le principe de fonctionnement est le même que pour IPv4, une requête (type 128) est envoyée vers l'équipement dont on veut tester le fonctionnement, celui-ci répond par le message réponse d'écho (type 129). Le champ identificateur permet de distinguer les réponses dans le cas où plusieurs commandes ping seraient lancées simultanément sur la machine. Le champ numéro de séquence permet d'associer la réponse à une requête pour mesurer le temps d'aller et retour dans le cas où les demandes sont émises en continu et que le délai de propagation est élevé. Le champ données permet d'augmenter la taille du message pour les mesures.

Le chapitre sur l'API, mini-ping, donne un exemple de programmation utilisant ces messages ICMPv6.

Format du paquet IPv6 Table des matières Exemples de paquets
Retrieved from "http://livre.g6.asso.fr/index.php?title=Format_du_message_ICMPv6&oldid=10615"
Personal tools