Résumé

  • RFC 4950 définit un objet de pile de labels MPLS pour certains messages ICMP multiparties. L’extension couvre ICMPv4 et ICMPv6 et reprend la structure ainsi que les en-têtes d’objet de RFC 4884.
  • Le LSR peut joindre la pile telle qu’elle est arrivée au routeur qui signale l’erreur, tout en conservant l’en-tête IP original et les premiers octets de charge utile. L’objet peut accompagner Time Exceeded et Destination Unreachable.
  • Un traceroute enrichi peut montrer les nœuds visités et l’état d’encapsulation MPLS du datagramme original à chaque nœud répondant, selon le support, la politique, le filtrage et le comportement TTL.

Le mécanisme opérationnel répond à une lacune précise. Quand un datagramme encapsulé en MPLS devient impossible à acheminer et qu’un LSR produit une erreur admissible, l’ICMP ordinaire peut montrer le datagramme IP exposé sans montrer les labels qui ont participé au traitement. RFC 4950 ajoute alors un objet d’extension RFC 4884 portant la pile entrante complète. Il ne remplace pas la preuve ICMP existante : l’en-tête IP original et les premiers octets de la charge utile doivent toujours être conservés.

Chaque entrée de pile occupe exactement quatre octets. Dans la description de RFC 4950, elle contient un label de 20 bits, trois bits à usage expérimental nommés ainsi dans le texte de 2007, un bit indiquant le bas de pile et un TTL de huit bits. Ces champs décrivent ce qui est arrivé au routeur signalant l’événement. Ils ne constituent ni une commande de réparation, ni une autorisation de route ou de LSP, ni une authentification, ni une autorisation d’accès, ni une preuve cryptographique. Une valeur de label divulguée ne donne pas la permission de modifier le transfert et ne prouve ni propriété, ni intention, ni conformité à une politique.

Le premier dispositif de vérification est une capture de paquets contenant le type et le code ICMP, l’en-tête d’extension RFC 4884, l’objet de pile MPLS et son en-tête d’objet. Il faut décoder chaque entrée de quatre octets, consigner le label, les bits expérimentaux, le bit de bas de pile et le TTL, puis conserver séparément l’en-tête IP cité et les premiers octets de charge utile. Une comparaison avec une réponse ICMP classique et avec les observations de traceroute au même point permet de distinguer les données effectivement vues des suppositions sur le chemin complet.

Un second dispositif est une matrice contrôlée. Selon la politique locale, varier la destination, la durée de vie de la sonde et la profondeur de pile reçue. Pour chaque réponse, relever s’il s’agit de Time Exceeded ou de Destination Unreachable, si l’objet est présent, combien d’entrées sont renvoyées et si le filtrage ou un équipement intermédiaire modifie le résultat. Chaque résultat reste l’observation locale d’un routeur rapporteur : il ne prouve ni le chemin de bout en bout, ni la cause racine, ni une information identique à chaque saut.

RFC 4950 ne définit pas la relation générale entre MPLS et ICMP, ni une manipulation du TTL propre à une encapsulation. Les comportements de TTL décrits dans le contexte de RFC 3032 influencent donc la visibilité de traceroute, mais cette extension ne choisit pas le modèle TTL. Une procédure qui neutralise le traceroute classique peut aussi neutraliser sa version enrichie. La mention, dans le RFC, d’un déploiement largement répandu est historique ; elle ne prouve ni la couverture actuelle, ni un comportement uniforme des implémentations, ni les valeurs actuelles par défaut de divulgation.

Les opérateurs peuvent divulguer sélectivement l’information MPLS selon leur politique, par exemple en fonction de l’adresse de destination, d’une configuration globale ou de la profondeur de pile entrante. Il s’agit d’une décision de gouvernance, pas d’une garantie du protocole. L’absence de l’objet ne prouve pas l’absence d’encapsulation MPLS : le manque de support, la politique, le filtrage, la compatibilité et le TTL peuvent tous empêcher l’observation.

Sources