Résumé

  • Dans ICMPv4, Parameter Problem rejetait le datagramme mais pouvait indiquer, avec un pointeur de huit bits, l’octet de l’en-tête où l’erreur avait été détectée.
  • ICMPv6 a porté ce pointeur à 32 bits et distingué champ erroné, Next Header inconnu et option inconnue. Le décalage suit ainsi une chaîne d’en-têtes d’extension.
  • Le pointeur peut viser au-delà des octets cités dans la réponse. Il exprime une position déclarée, pas une preuve complète, une authentification ni un droit de lire hors du tampon reçu.

Le datagramme n’était pas réparable

Le RFC 792 ne promettait pas de corriger un en-tête IPv4 fautif. Lorsqu’un hôte ou une passerelle rencontrait un paramètre qui empêchait de poursuivre, le datagramme devait être abandonné. L’innovation de septembre 1981 tenait à ce qui pouvait suivre l’abandon : un message ICMP de type 12, Parameter Problem.

Son champ Pointer occupait un octet. Avec le code 0, sa valeur désignait l’octet de l’en-tête original où l’erreur avait été repérée. Le décalage 1 pouvait désigner le champ Type of Service ; 20, lorsqu’une option existait, le type de la première option. Le pointeur pouvait même tomber au milieu d’une option. Il ne décrivait pas une catégorie abstraite : il donnait une coordonnée dans les octets effectivement analysés.

La réponse reprenait aussi l’en-tête Internet et les 64 premiers bits de données. Pour TCP ou UDP, ces huit octets pouvaient contenir les ports utiles à l’identification du processus émetteur. La citation disait à quelle émission rattacher l’incident ; le pointeur disait où le lecteur distant avait cessé de comprendre.

Cette précision ne transformait pas IP en service fiable. Le même RFC rappelait qu’ICMP fournit un retour sur l’environnement de communication sans garantir qu’un message sera renvoyé pour chaque perte. L’absence de Parameter Problem reste donc compatible avec un abandon, un filtrage, une limitation de débit ou une perte du rapport lui-même.

Informer sans laisser le diagnostic prendre le contrôle

Le RFC 1122 a converti le format en exigence de comportement pour les hôtes. Quand le processus d’origine peut être reconnu, l’information doit remonter vers la couche concernée. Pour TCP, Parameter Problem est à signaler ; il n’est pas, par sa seule présence, un ordre universel d’interrompre la connexion. La couche qui connaît l’état garde la décision.

Le texte de 1989 insistait aussi sur la journalisation des événements étranges. Conserver les en-têtes aide à diagnostiquer un Internet composé d’implémentations différentes. Mais une pluie d’anomalies bénignes ne doit pas remplir les journaux ni voler les ressources nécessaires au service. La qualité du diagnostic se mesure donc avec sa limite de coût.

Le RFC 1812 a appliqué cette prudence aux routeurs IPv4. Un paquet invalide doit être rejeté et, en règle générale, journalisé. Dans des cas où suffisamment d’octets restent fiables, le routeur peut renvoyer Parameter Problem en pointant Internet Header Length ou Total Length. Il peut néanmoins hésiter entre troncature de liaison, corruption, autre version d’IP ou fabrication illégale par la source. L’emplacement du contrôle qui échoue n’identifie pas automatiquement la cause première.

La citation a été autorisée à grandir : autant d’octets que possible, sans porter le message ICMP au-delà du tampon minimal de réassemblage IPv4 de 576 octets. Le diagnostic gagnait du contexte tout en conservant une barrière contre l’amplification.

Avec IPv6, la position quitte l’en-tête fixe

Le maximum de 60 octets de l’en-tête IPv4 rendait un pointeur de huit bits suffisant. IPv6 place au contraire les informations facultatives dans une succession ordonnée d’en-têtes après une base fixe de 40 octets. Le champ Next Header de chaque élément indique ce qui doit être lu ensuite. Une erreur peut donc se trouver loin de la base.

Le RFC 2463 a défini en 1998 le Parameter Problem d’ICMPv6 : type 4, pointeur de 32 bits et trois codes. Le code 0 signale un champ d’en-tête erroné ; le code 1, un Next Header inconnu ; le code 2, une option IPv6 inconnue. Le RFC 4443 a conservé cette structure en 2006.

L’exemple Pointer 40, Code 1, situe l’inconnu exactement à la transition qui suit l’en-tête IPv6 de base. Le nombre n’est ni une gravité ni un identifiant de protocole. C’est un décalage depuis le début du paquet invoquant.

Le RFC 8200 donne sa portée opérationnelle. Les en-têtes d’extension sont traités dans leur ordre. Un destinataire ne peut pas sauter une transition incomprise pour chercher plus loin un protocole familier. S’il doit continuer mais ne reconnaît pas la valeur Next Header, il rejette et pointe cette valeur. Certaines options inconnues demandent pareillement le code 2 ; leur logique de bits d’action demeure un autre sujet.

Le pointeur marque ainsi la frontière du savoir d’un analyseur. Il ne garantit pas que les champs postérieurs ont été inspectés, ni que le reste du paquet serait valide.

Une coordonnée au-delà de la pièce jointe

Chaque erreur ICMPv6 doit citer autant du paquet invoquant que possible sans dépasser le MTU IPv6 minimal. Une longue chaîne d’extensions peut placer le champ fautif au-delà de cette citation. Le RFC 4443 choisit alors de préserver le vrai décalage : le pointeur peut se trouver au-delà de la fin des octets invoquants présents dans le message ICMPv6.

La source reçoit deux informations compatibles. Le rapporteur affirme avoir bloqué au décalage N. La réponse, elle, ne contient pas l’octet N. Ramener le pointeur au dernier octet disponible accuserait le mauvais champ ; agrandir sans limite la réponse sacrifierait le contrôle des ressources. Le protocole garde la précision et rend l’absence visible.

Une application ne peut donc pas utiliser la valeur comme indice de mémoire sans vérifier la longueur du tampon. Le RFC 8883 l’énonce explicitement : avant de lire à l’emplacement indiqué, il faut confirmer que le pointeur est inférieur à la quantité de données invoquantes effectivement reçues.

La troncature peut aussi cacher le protocole supérieur. Si celui-ci ne peut être extrait de la citation, le système risque de ne pouvoir identifier aucun processus à prévenir. Une coordonnée réseau précise n’assure ni une citation complète ni la livraison du diagnostic à l’application.

Le pointeur mesure aussi les limites locales

En 2020, le RFC 8883 a ajouté des codes pour un Next Header inconnu vu par un nœud intermédiaire et pour plusieurs limites de traitement : en-tête d’extension trop grand, chaîne trop longue, trop d’en-têtes, trop d’options ou option trop grande. Selon le code, le pointeur vise la valeur inconnue, le premier octet au-delà d’une limite ou le premier élément qui dépasse un compte.

Le paquet n’est plus nécessairement mal formé. Il peut respecter la syntaxe et dépasser le budget d’analyse d’un nœud. Le code nomme la classe de limite locale ; le décalage indique où elle a été franchie. Un autre équipement pourrait accepter exactement la même chaîne.

Cette évolution protège une distinction politique : le standard n’oblige pas chaque nœud à consacrer des ressources infinies à toute extension, mais un refus local ne devient pas pour autant un verdict universel sur le paquet. Le rapport doit rester attribuable à celui qui a atteint sa limite.

Une preuve à confronter, jamais un ordre nu

Les erreurs ICMP ne sont pas authentifiées par défaut. Le RFC 4443 décrit l’usurpation de source, la modification des champs et l’usage d’ICMP contre les couches supérieures. Avant d’agir, la source doit corréler les adresses, le protocole, les ports et les paquets récemment émis. Même réussie, cette vérification ne reconstitue pas tout le chemin.

Les nœuds IPv6 doivent aussi limiter le débit de leurs erreurs. Une source défaillante ou hostile ne doit pas transformer le diagnostic en charge permanente. Filtrage, règles multicast et pertes ordinaires créent d’autres silences. Un message reçu atteste qu’un rapporteur a formulé cette observation ; aucun message ne prouve pas une analyse réussie partout.

Parameter Problem a rendu quatre faits séparément observables : le paquet a été rejeté, un code décrit la raison choisie, un pointeur situe l’arrêt et une citation fournit seulement le contexte qui tient dans la limite. Cette séparation est plus durable qu’une promesse de diagnostic total.

Sources