Mon blog

Le protocole ICMP permet d'inclure une partie du datagramme qui a déclenché l'émission du paquet ICMP. Avec ce RFC, cette partie est désormais dotée d'une structure, permettant son analyse et sa transformation.

ICMP (RFC 792) sert à beaucoup de choses mais une de ses utilisations les plus connues est l'émission d'un paquet ICMP par un routeur lorsqu'un datagramme ne peut pas être transmis par ce routeur, par exemple lorsqu'il n'existe pas de route vers la destination ou bien lorsque le nombre maximal de routeurs à franchir a été dépassé (cette dernière fonction est à la base de traceroute).

Pour aider à l'analyse du paquet ICMP (quel datagramme a déclenché le problème ? à qui était-il destiné ? que contenait-il ?), ICMP prévoit depuis la début la possibilité d'inclure le début du datagramme « fautif » dans le paquet ICMP. Mais ce bout de datagramme n'avait pas de structure précise, même pas d'indication de sa longueur, et son analyse était donc parfois délicate.

Notre RFC introduit donc un nouveau concept, le message ICMP en plusieurs parties, un peu comme ce que MIME avait fait pour le courrier électronique. Certains messages ICMP peuvent donc désormais contenir plusieurs objets, chaque objet ayant un en-tête et contenant des données structurées.

Comme souvent dans l'Internet, la compatibilité avec la version précédente du protocole était le principal problème. Que va faire une application moderne qui traite l'ICMP si un vieux routeur lui envoie des paquets ICMP de l'ancienne norme ? Et dans le cas inverse ? Notre RFC consacre donc une longue section 5 à ce problème et en conclut que peu d'inconvénients devraient être visibles.

Ces types d'objets sont enregistrés dans un registre IANA, https://www.iana.org/assignments/icmp-parameters. Le premier RFC à utiliser cette extension est le RFC 4950 sur MPLS, le second a été le RFC 5837 sur les informations d'interface, mais plusieurs autres RFC en préparation créent de tels objets.