Latest revision as of 23:31, 19 April 2022

Activité 23 : Le contrôle par ICMPv6 de l'acheminement des paquets IPv6

Introduction

Les réseaux physiques constituant Internet sont susceptibles d'être défaillants de manière plus ou moins fréquentes. Il peut s'agir d'une panne d'un équipement intermédiaire (routeur, commutateur) ou d'un lien (rupture d'un câble souterrain par une pelleteuse par exemple). L'Internet est normalement prévu pour exploiter des chemins alternatifs pour continuer à assurer l'acheminement des paquets, mais la détection et la gestion de ces incidents nécessitent des mécanismes de contrôle. Le réseau peut aussi détecter des problèmes d'acheminement liés à la nature de certains paquets : taille des données trop importante, en-tête comportant une adresse invalide ou ne correspondant à aucun équipement, etc.

Le protocole IPv6 prévoit donc un mécanisme permettant de signaler ces problèmes d'acheminement. Les messages correspondant à cette signalisation sont spécifiés dans le protocole ICMPv6 (RFC 4443). Il permet au réseau d'informer la source d'un paquet que celui ne peut pas être acheminé et en signifie la raison. C'est un mécanisme similaire au retour à l'expéditeur dans le réseau postal.

Format général d'un message ICMPv6

Les messages ICMPv6 sont encapsulés directement dans un paquet IPv6. Le protocole se voit attribuer le numéro 58 pour être représenté dans l'en-tête IPv6 comme prochain en-tête (champ Next Header). Le format général des messages ICMPv6 est donné par la figure 1. L'en-tête des messages ICMPv6 comporte 3 champs :

1. Le champ Type : il indique la nature du message ICMPv6 et donc, le format spécifique du message. Les messages ICMPv6 forment 2 groupes : un groupe pour les messages d'informations et un autre pour les messages d'erreurs. Les groupes sont identifiés par le bit de poids fort de ce champ. Les messages d'erreurs ont ce bit à zéro et donc, le champ Type prendra, pour ces messages, une valeur comprise entre 0 et 127. Les messages d'informations sont identifiés par un champ Type dont la valeur est comprise entre 128 et 255.
2. Le champ Code s'interprète dans le contexte du type de message. Il est utilisé pour ajouter une granularité plus fine au type.
3. Le champ Checksum sert à vérifier l'intégrité du message ICMP. Il porte aussi bien sur l'en-tête du message que sur sa charge utile.

Figure 1 : Format d'un message ICMPv6.

La charge utile du message ICMPv6 (message body) est relative au contexte fonctionnel :

• dans le cas des messages de compte rendu d'erreurs, elle contient le paquet IPv6 ayant provoqué l'erreur. Pour éviter d'avoir à fragmenter, la longueur du message ICMPv6 est limitée à 1 280 octets. Par conséquent, le contenu du paquet IPv6 renvoyé peut être tronqué ;
• pour les messages de découverte du voisinage, la charge utile est composée de différentes options selon qu'il s'agisse d'une sollicitation de voisin ou d'une annonce de voisin ;
• les messages de test d'accessibilité embarquent des données de taille et de contenu quelconque.

Les messages sont spécifiés dans différents RFC. Cependant, la liste complète des types de messages et les différents paramètres associés sont regroupés par l'IANA (Internet Assigned Number Authority)^[1]. Le tableau 1 présente les valeurs et les codes définis dans le RFC 4443. Ce qu'il faut noter, c'est que les valeurs de type inférieures à 128 sont pour les messages d'erreurs et qu'à partir de 128, ce sont des messages d'informations.

Test d'accessibilité d'un nœud

Les test d'accessibilité vise à vérifier qu'un nœud est joignable par l'adresse IPv6 de son interface. Autrement dit, depuis un nœud, on vérifie qu'il existe une connectivité entre deux nœuds de l'Internet. Ce test est couramment utilisé, notamment à l'aide de l'outil nommé ping.Le principe de fonctionnement est le même que pour IPv4. Un message de demande d'écho (echo request), message ICMPv6 type 128 est envoyé vers le nœud dont on veut tester la connectivité. Ce dernier répond par le message "réponse d'écho" (echo reply), message ICMPv6 de type 129. Le format de ces deux messages est présenté par la figure 2.

Figure 2 : Format du message d'écho.

Les réponses sont identifiées par le champ identifiant. Ainsi, la réponse est rapprochée de la requête. Ceci est particulièrement utile quand plusieurs commandes ping sont exécutées simultanément sur la machine. Le champ numéro de séquence complète le mécanisme de rapprochement de la réponse à la requête et va servir à mesurer la durée d'aller et retour dans le cas où les demandes sont émises en continu et que le délai de propagation est élevé. La réponse doit toujours contenir les mêmes valeurs que la requête pour ces deux champs. Le champ données permet d'augmenter la taille du message (et donc la durée de transmission) pour les mesures.

Pour illustrer le test d'accessibilité, observons l'échange suivant : Le nœud nommé "Uma" teste la connectivité du nœud "Ganesha" via la commande ping6. La commande entrée sur Uma est la suivante :

uma# ping6 ganesha
trying to get source for ganesha
source should be 2001:db8:12:3:a00:20ff:fe0a:aa6d
PING ganesha (2001:db8:12:3::3): 56 data bytes
64 bytes from 2001:db8:12:3::3: icmp6_seq=0 ttl=255 time=5.121 ms

Les messages ICMPv6 obtenus sont les suivants.

• Le nœud "Uma", qui est l'initiateur, envoie un message ICMPv6 Demande d'écho. La trace 1 montre un paquet IPv6 contenant un message ICMPv6 Demande d'écho (en bleu dans la trace).

Version : 6	Classe : 0x00	Label : 000000 Longueur : 64 octets (0x0040)
Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 64 (0x40)
Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (Uma) 
Desti. : 2001:db8:12:3::3 (Ganesha) 
ICMPv6  
Type : 128 (0x80, Demande d'écho)	Code : 0 Checksum : 0xcfe8
Identificateur : 0x0e02	Numéro de séquence : 0x0001 
Données : b6e0 f056 ...

0000:  6000 0000 0040 3a40 2001 0db8 0012 0003
0010:  0a00 20ff fe0a aa6d 2001 0db8 0012 0003
0020:  0000 0000 0000 0003|80|00|cfe8|0e02|0001|
0030:  b6e0 f056 d947 0700 0809 0a0b 0c0d 0e0f
0040:  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0050:  2021

• Le destinataire du message "Demande d'écho", qui est Ganesha sur la figure 10, acquitte ce message en retournant un message ICMPv6 Réponse d'écho (voir la trace 2).

Version : 6	Classe : 0x00	Label : 000000 Longueur : 64 octets (0x0040)
Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 64 (0x40)
Source : 2001:db8:12:3::3 (Ganesha)
Desti. : 2001:db8:12:3:a00:20ff:fe0a:aa6d (Uma)  
ICMPv6  
Type : 129 (0x81, Réponse d'écho)	Code : 0 Checksum : 0xcee8
Identificateur : 0x0e02	Numéro de séquence : 0x0001 
Données : b6e0 f056 ...

0000:  6000 0000 0040 3a40 2001 0db8 0012 0003
0010:  0000 0000 0000 0003 2001 0db8 0012 0003
0020:  0a00 20ff fe0a aa6d|81|00|cee8|0e02|0001|
0030:  b6e0 f056 d947 0700 0809 0a0b 0c0d 0e0f
0040:  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0050:  2021

Messages ICMPv6 de rapport d'erreur

ICMPv6 permet de signaler, à l'émetteur d'un paquet, un problème dans son acheminement ou dans sa réception, par des messages de rapport d'erreur. Lorsqu'une machine émet un paquet, si une erreur est détectée par le destinataire ou par tout routeur intermédiaire le long du chemin vers le destinataire, alors l'élément qui détecte l'erreur renvoie à l'émetteur un rapport sous la forme d'un message ICMPv6. Le type du message et son code définissent précisément l'erreur détectée. L'extrait, jusqu'à concurrence de 1280 octets du paquet en défaut, est incluse pour permettre l'analyse de l'erreur. L'exemple ci-dessous illustre un message ICMP Paquet trop grand, généré par un routeur intermédiaire dès qu'un datagramme ne peut être retransmis en raison de la limitation de la MTU sur son interface de sortie.

Figure 4 : Format du message ICMPv6 Paquet trop grand.

Différentes erreurs peuvent être signalées par ICMPv6. Les cas les plus courants sont :

• destination inaccessible (type 1), la raison est précisée par le champ Code ;
• paquet trop grand (type 2) ;
• délai expiré (type 3) ;
• erreur de paramètre (type 4).

Chaque cas d'erreur est défini par un message ICMP. Nous allons voir les cas d'erreurs rapportées par ICMPv6.

Destination inaccessible

Un message ICMP Destination Unreachable est généré dès qu'un datagramme ne peut être traité. Le format de ce message est présenté par la figure 3.

Figure 3 : Format du message de Destination inaccessible.

Ce message est émis par un routeur quand le paquet ne peut pas être transmis pour l'une des raisons suivantes :

• le routeur ne trouve pas dans ses tables la route vers la destination (code = 0) ;
• le franchissement d'un pare-feu (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 à un rejet du paquet (code = 6).

Le champ de données contient tout ou partie du datagramme IP qui a occasionné ce message d'erreur.

Paquet trop grand

Si un routeur ne peut pas relayer le datagramme IP parce que celui-ci a une taille supérieure à la MTU (Maximum Transmission Unit) du lien de sortie, il émet le message d'erreur Packet Too Big. Les routeurs en IPv6 ne sont plus habilités à effectuer la fragmentation. Le format du message est représenté par la figure 4.

Figure 4 : Format du message ICMPv6 Paquet trop grand.

Ce message ICMPv6 est utilisé par le protocole de découverte de la MTU pour trouver la taille optimale des paquets IPv6 afin qu'ils puissent traverser les routeurs. Ce mécanisme, spécifié par le RFC 8201, est décrit dans la séquence 2. 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. Pour IPv4, le RFC 1191 proposait déjà une modification du comportement des routeurs pour y inclure cette information. À noter que le RFC 4443 indique que ce message n'est pas produit dans le cas d'une communication multicast.

Délai expiré

Quand un routeur relaie un datagramme, il décrémente la valeur du nombre de sauts(Hop Limit) de 1. Ce champ, dans l'en-tête IPv6, limite la durée de vie d'un paquet dans le réseau. La durée de vie est exprimée en nombre de routeurs traversés (ou sauts). Si un routeur reçoit un datagramme avec un nombre de sauts de 1, la décrémentation amène la valeur de ce champ à zéro. Le routeur supprime le datagramme et en avertit la source à l'aide du message Délai expiré (Time Exceeded) (voir la figure 5). Le signalement de cette erreur peut indiquer une boucle dans le réseau au niveau du routage ou que l'émetteur a positionné une valeur de nombre de sauts trop faible. Le dernier cas peut provenir d'un paquet émis par la commande traceroute. Cette commande vise à déterminer le chemin pris par les datagrammes ^[2].

Figure 5 : Format du message de délai expiré.

Le message ICMPv6 Délai expiré indique que le paquet a été rejeté :

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

Erreur de paramètre

Le message Parameter problem est émis quand un paquet IPv6 ne peut être traité par un nœud du fait d'un problème dans l'en-tête du paquet ou dans ses extensions d'en-tête. Le paquet IPv6 est supprimé mais le nœud envoie à la source le message ICMPv6 dont le format est présenté par la figure 6.

Figure 6 : Format du message Erreur de paramètre.

Le champ type prend la valeur 4. 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é. Le message contient tout ou partie du paquet IPv6 qui a occasionné le message lui-même.

Attention au filtrage d'ICMPv6

Contrairement à une pratique couramment répandue en IPv4, il ne faut jamais filtrer l'ensemble des messages ICMPv6 en entrée d'un réseau (en particulier le message "Paquet trop grand"). Le filtrage peut introduire des effets néfastes sur le fonctionnement du réseau^[3]. Supposons que la MTU entre un client et un serveur soit limitée à 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 requête HTTP qui est elle-même de petite taille. Le serveur va répondre en envoyant une page complète. Si le paquet a une longueur de 1500 octets, il va être détecté trop grand par le routeur à l'entrée du tunnel. Ce dernier va rejeter le paquet et envoyer au serveur un message ICMPv6 indiquant que le paquet est trop grand. Si le pare-feu du serveur le filtre, le serveur ne connaitra jamais la taille de la MTU adaptée au chemin qui mène à ce client. Il ne pourra pas adapter la taille de ses paquets. Tous les paquets de 1500 octets seront inexorablement supprimés. Le client devient alors quasiment injoignable et c'est le service de connectivité de la couche "réseau" qui est cassé. Dans cette situation, on se trouve dans une situation où certains paquets passent (ouvertures de connexion, ping, sessions SSH...) et d'autres sont bloqués. Diagnostiquer ce type d'erreur est particulièrement délicat.

Comme ICMPv6 est essentiel au fonctionnement d'IPv6, le RFC 4890 donne les bonnes pratiques pour filtrer correctement les messages ICMPv6. L'idée est de laisser passer les messages ICMPv6 qui sont indispensables au fonctionnement du réseau et de jeter ceux qui introduisent un risque d'insécurité.

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer :

• RFC 1191 Path MTU Discovery
• RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
• RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Analyse
• RFC 4620 IPv6 Node Information Queries
• RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls
• RFC 8201 Path MTU Discovery for IP version 6 Analyse
• RFC 8883 ICMPv6 Errors for Discarding packets Due to Processing Limits Analyse

Annexe 1 : Autres fonctions d'ICMPv6

Le contenu de cette annexe complète l'activité 23 en :

• introduisant MLD, le protocole de gestion des inscriptions aux groupes de multicast et les messages ICMPv6 associés ;
• introduisant des fonctions expérimentales ;

Gestion de groupes multicast sur le lien local

Pour offrir un service de distribution multicast, deux composants sont nécessaires : un protocole de gestion de groupes multicast et un protocole de routage multicast^[4]. Le protocole de gestion de groupes multicast réalise la signalisation entre l'hôte et son routeur local. Le protocole de routage multicast vise à échanger les informations entre les routeurs afin qu'un arbre de distribution multicast soit construit.

En IPv6, MLD (Multicast Listener Discovery) sert, pour un hôte, à indiquer les groupes auxquels il souhaite souscrire. MLD est donc un protocole de gestion de groupes. Ainsi, un routeur de bordure IPv6 va pouvoir découvrir la présence de récepteurs multicast (qualifiés de listeners) sur ses liens directement attachés, ainsi que les adresses multicast concernées. MLD est un protocole asymétrique qui spécifie un comportement différent pour les hôtes (les listeners) et les routeurs. Toutefois, pour les adresses multicast sur lesquelles un routeur lui-même est récepteur, il doit exécuter les deux parties du protocole. Ceci implique notamment de répondre à ses propres messages de demande. En effet, les routeurs doivent constituer une liste des adresses multicast pour lesquelles il a un ou plusieurs récepteurs sur leur lien local. Aussi, un des récepteurs sur un lien envoie un message de rapport d'abonnement aux groupes auxquels il souhaite recevoir les messages. L'objectif est, par des communications multicast sur le lien, que le routeur local arrive à faire la liste complète des groupes multicast pour lesquels il doit relayer le trafic localement.

MLD est une fonction d'ICMPv6 ; aussi, les messages MLD sont des messages ICMPv6. Les messages pour MLD sont envoyés avec :

• une adresse source IPv6 lien-local ;
• le champ nombre de sauts fixé à 1 ;
• l'option IPv6 Router Alert activée en ajoutant l'extension d'en-tête Hop-by-Hop correspondante.

Cette dernière option est nécessaire afin de contraindre les routeurs à examiner les messages MLD envoyés à des adresses multicast par lesquelles les routeurs ne sont pas intéressés. La version d'origine du protocole MLD [RFC 2710] (que nous appellerons également MLDv1) présente les mêmes fonctionnalités que le protocole IGMPv2 en IPv4. MLDv2 a été proposé par le RFC 3810 dans lequel, en plus du groupe, le récepteur peut indiquer la source. MLDV2 est une adaptation de IGMPv3 d'IPv4 à IPv6.

Format des messages pour MLD

Le format générique d'un message MLD est donné par la figure 7. Les différents types de messages ICMPv6 pour MLD sont indiqués par le tableau 2. On distingue trois types de messages pour MLD.

1. Le premier type (type = 130) concerne le recensement des récepteurs multicast selon plusieurs méthodes : (i) recensement général émis à l'adresse de diffusion générale sur le lien (FF02::1), (ii) recensement spécifique pour une adresse multicast ; l'adresse de destination est l'adresse multicast du groupe en question. Le message de requête d'abonnement (Multicast Listener Query) est émis par le routeur.
2. Le second type de message (type = 131) vise à obtenir un rapport d'abonnement multicast (Multicast Listener Report). Ce message est émis par le récepteur multicast. L'adresse de destination est l'adresse multicast du groupe en question. Avec MLDv2, le rapport d'abonnement à un groupe multicast a été complété par la possibilité de limiter la réception au trafic émis par certaines sources. Le trafic des sources non indiquées est alors non reçu. Cette restriction sur la source s'effectue par un message spécifique (type = 143).
3. Enfin, le troisième type de message (type = 132) va servir à un récepteur pour annoncer une résiliation d'abonnement (Multicast Listener Done) à un groupe. Ce message est émis à l'adresse du groupe multicast "tous les routeurs du lien local" (FF02::2).

Les champs des messages pour MLD ont la signification suivante :

• Type : prend la valeur 130, 131 ou 132 ;
• Code : mis à zéro par l'émetteur et ignoré par les récepteurs ;
• Checksum : celui du protocole ICMPv6 standard, couvrant tout le message MLD auquel s'ajoutent les champs du pseudo-en-tête IPv6 ;
• Délai maximal de réponse :
  • utilisé seulement dans les messages de recensement, il exprime le retard maximal autorisé (en millisecondes) pour l'arrivée des rapports d'abonnement,
  • dans les messages de rapport ou de résiliation d'abonnement, ce champ est mis à zéro par l'émetteur et ignoré par les récepteurs ;
• réservé : champ non utilisé et mis à zéro par l'émetteur et ignoré par les récepteurs ;
• Adresse multicast :
  • pour un message de recensement général, ce champ est mis à zéro,
  • pour un message de recensement spécifique, il contient l'adresse multicast en question,
  • pour les messages de rapport et de résiliation d'abonnement, le champ contient l'adresse multicast sur laquelle l'hôte souhaite écouter ou cesser d'écouter.

Figure 7 : Format générique d'un message ICMPv6 pour MLD.

Principe de MLD

Le routeur envoie régulièrement des messages de recensement général à l'adresse de multicast FF02::1. Cette adresse équivaut à l'adresse de diffusion sur un lien. Pour éviter que le routeur reçoive plusieurs réponses pour un même groupe, les récepteurs ne répondent pas immédiatement. Pour cela, les récepteurs arment un temporisateur pour chaque adresse multicast qui les concerne. Si le récepteur entend une réponse équivalente à la sienne, Il désarme le temporisateur. Sinon, à l'expiration du temporisateur, le récepteur envoie un rapport d'abonnement à l'adresse multicast du groupe. Avec ce système de temporisateurs, les récepteurs peuvent surveiller les rapports des autres récepteurs sur le lien et ainsi minimiser le trafic MLD.

Les changements d'état des récepteurs sont notifiés par des messages non sollicités. Un message non sollicité est un message émis à l'initiative d'un récepteur d'un groupe multicast ; contrairement au recensement, où c'est le routeur local qui prend l'initiative de l'échange. Les récepteurs peuvent envoyer des messages non sollicités pour les cas suivants :

• pour souscrire à une adresse multicast spécifique ;
• pour une résiliation rapide : le récepteur envoie un message de résiliation d'abonnement à l'adresse multicast de "tous les routeurs du lien local" (FF02::2). Le routeur répond avec un message de recensement spécifique à l'adresse en question. S'il n'y a plus de récepteur pour répondre à ce recensement, le routeur efface l'adresse multicast de sa table de routage.

Pour cesser d'écouter sur une adresse multicast, le récepteur peut simplement ne plus répondre aux messages de recensement du routeur. S'il est le seul récepteur de cette adresse multicast sur le lien, après un certain temps, l'état du routeur concernant cette adresse expire. Le routeur arrêtera de faire suivre les paquets multicast envoyés à l'adresse en question, s'il s'avère que le récepteur était le dernier concerné par l'adresse multicast sur le lien.

À noter qu'il est possible d'avoir plusieurs routeurs multicast sur le même lien local. Dans ce cas, un mécanisme d'élection est utilisé pour choisir le routeur recenseur. Celui-ci sera le seul responsable pour l'envoi des messages de recensement.

Fonctions autres et expérimentales

Pour être complet, nous pouvons signaler que les messages ICMPv6 servent aussi pour des fonctions expérimentales. Le tableau 4 indique les types de messages associés à ces fonctions. Nous ne détaillerons pas ici ces fonctions, limitées à des usages très spécifiques. Le lecteur curieux est invité à consulter les RFC associés.

Adresse physique de la source/cible

Figure : Format de l'option adresse physique source/cible.

La figure "Format de l'option adresse physique source/cible" donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible.

Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1.

Le RFC 2464 définit le format pour les adresses MAC-48 utilisés dans les réseaux Ethernet et Wi-Fi. Le RFC 4944 définit le format pour les MAC-16 et MAC-64 utilisés dans les réseaux de capteurs reposant sur la norme IEEE 802.15.4.

Information sur le préfixe

Figure : Format de l'option information sur le préfixe.

Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Cette option sera présentée en détail dans l'activité d'autoconfiguration.

En-tête redirigée

Figure : Format de l'option en-tête redirigée.

Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.

Le type vaut 4 et la taille de cette option ne doit pas conduire à un paquet IPv6 dépassant 1280 octets (cf. figure Format de l'option en-tête redirigée). Par contre le paquet doit contenir le maximum d'information possible.

MTU

Figure : Format de l'option MTU.

Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure "Format de l'option MTU" donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts.

Le champ type vaut 5 et le champ longueur 1.

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer

• RFC 2710 Multicast Listener Discovery (MLD) for IPv6
• RFC 2894 Router Renumbering for IPv6
• RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
• RFC 3971 SEcure Neighbor Discovery (SEND) Analyse
• RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6
• RFC 4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations
• RFC 6275 Mobility Support in IPv6

Référence bibliographique

1. ↑ IANA. Internet Control Message Protocol version 6 (ICMPv6) Parameters
2. ↑ Wikipédia Principe de l'utilitaire traceroute
3. ↑ Kline, E. and Townsley, M.; Google IPv6 Center. ICMPv6 is Non-Optional
4. ↑ Sébastien LOYE. (2005). Techniques de l'ingénieur. ref TE7527. Le multicast IP : principes et protocoles