Résumé

  • Une pile MPLS conservée dans une extension ICMP décrit l’état du paquet à l’entrée du routeur ; elle ne sert pas à acheminer cette erreur.
  • L’encapsulation utilisée pour transporter l’erreur peut suivre un détour. Elle ne doit pas être confondue avec la pile citée à titre de preuve.
  • Le format commun rend une observation lisible, mais ne garantit ni l’exhaustivité du chemin, ni l’identité globale des labels, ni leur divulgation à tous.

Le retour peut commencer dans le mauvais sens

Un routeur sait qu’il doit signaler un problème à l’émetteur d’un paquet. Cela ne signifie pas qu’il sait immédiatement lui renvoyer un message.

RFC 3032, publié en janvier 2001, expose notamment le cas d’un équipement intérieur à un domaine MPLS qui ne dispose pas des informations nécessaires pour joindre la source IP. Dans certaines configurations, une solution consiste à encapsuler le message ICMP et à le faire progresser d’abord dans la direction de la destination du paquet initial. Il atteindra ainsi un routeur capable de l’orienter vers sa source.

Les valeurs des labels peuvent être reprises, mais les TTL sont réglés pour le voyage du nouveau message. Ce dernier doit pouvoir supporter le détour. Il ne s’agit pas d’une prescription universelle pour tous les réseaux : c’est une technique décrite pour des situations où le retour direct pose problème.

Quelques années plus tard, une autre manière de mettre des labels dans une erreur ICMP sera formalisée. Cette fois, ils ne dirigeront pas le message. Ils en constitueront une partie du contenu, destinée à raconter dans quel état le paquet initial était arrivé.

Confondre ces deux usages reviendrait à prendre l’enveloppe qui transporte un rapport pour une photographie conservée dans ce rapport.

Le contexte retiré avant de rédiger l’erreur

RFC 4950, daté d’août 2007, part d’une perte très précise. Lorsqu’un routeur à commutation de labels reçoit un datagramme MPLS impossible à remettre, il retire toute la pile pour exposer le datagramme IP. Celui-ci est alors soumis au traitement des erreurs.

Une éventuelle réponse ICMP indique le problème et reproduit l’en-tête IP ainsi que les premiers octets du contenu original. Mais la pile présente à l’arrivée a disparu. Or c’est précisément à partir de cette pile que l’équipement aurait pris sa décision de transfert.

Le rapport peut donc être exact et néanmoins incomplet sur le mécanisme en cause. Il cite le paquet, sans citer la couche de contexte qui commandait son acheminement.

Ronald P. Bonica, Der-Hwa Gan, Daniel C. Tappan et Carlos Pignataro définissent un objet d’extension permettant de joindre cette pile entrante aux erreurs sélectionnées. Le document recommande son inclusion et exige que la citation IP reste présente. La nouvelle pièce n’efface pas l’ancienne : elle répond à une question différente.

Le mot « arrivée » est essentiel. Le rapport ne prétend pas décrire la pile qui serait sortie du routeur après traitement. Il ne donne pas davantage la configuration actuelle de l’équipement lorsqu’un lecteur consulte l’archive plusieurs mois plus tard.

Ce que l’ancienne citation cherchait à reconnaître

Dans RFC 792, en septembre 1981, le message Time Exceeded comprend l’en-tête IP et les 64 premiers bits de données du datagramme initial. Ces huit octets servent à rattacher l’erreur au processus concerné, notamment grâce aux numéros de port lorsque le protocole supérieur en utilise.

La question première est celle de la correspondance : à quelle communication ce problème appartient-il ? Elle n’est pas celle d’un relevé exhaustif des décisions prises en route. Cette description historique ne signifie pas que toutes les variantes ultérieures d’ICMP auraient conservé une limite immuable de huit octets.

MPLS ajoute une raison particulière de distinguer les deux questions. Sa pile se trouve avant l’en-tête IP, après les en-têtes de liaison. Allonger la citation vers la suite du datagramme IP ne ramène donc pas naturellement les labels précédemment retirés.

RFC 3032 donne à chaque entrée de pile une taille de quatre octets. L’entrée du sommet arrive la première ; le bit S marque la dernière. La consultation du label supérieur permet de déterminer un prochain saut et une opération sur la pile : remplacement, retrait, ou ajout d’entrées après remplacement. La couche omise n’est pas un simple commentaire décoratif.

Une valeur locale n’est pas une adresse universelle

RFC 3031, également publié en janvier 2001, décrit le label comme un identifiant de portée locale désignant une classe d’équivalence de transfert. Ce n’est pas une autre écriture de l’adresse IP de destination.

Une même valeur imprimée à deux endroits n’assure donc pas une même signification. Il faut connaître le contexte et l’espace de labels applicables. Les nombres affichés par plusieurs routeurs ne forment pas, par leur seule ressemblance, les noms permanents des segments d’un parcours.

L’extension de 2007 normalise le contenant, non ces attributions locales. La classe 1 identifie l’objet MPLS Label Stack et le sous-type 1 la pile entrante. Cette attribution commune permet au logiciel de comprendre la structure du témoignage. Elle ne transforme pas les nombres qu’il contient en identifiants distribués par une autorité mondiale.

La distinction est discrète mais décisive. Une convention de lecture peut traverser les réseaux sans que l’organisation qui en tient le registre commande les décisions de transfert dans chacun d’eux.

Un objet, toute la pile entrante

RFC 4950 permet d’ajouter l’objet aux messages Time Exceeded et Destination Unreachable, pour ICMPv4 comme pour ICMPv6. Il ne l’étend pas indistinctement à tous les messages ICMP.

Un seul objet représente la pile complète, dans l’ordre où elle est arrivée. Sa longueur vaut quatre octets d’en-tête d’objet, plus quatre octets par entrée. Avec trois entrées, on obtient seize octets. Ce calcul illustre la structure ; il ne décrit pas une mesure effectuée sur un réseau. L’en-tête général d’extension, placé auparavant, ne fait pas partie de cette longueur.

Chaque entrée comprend vingt bits de label, trois bits alors appelés EXP, un bit S et huit bits de TTL. En février 2009, RFC 5462 remplace le nom EXP par Traffic Class, ou TC, pour clarifier leur usage. Il ne crée pas un nouveau format de taille supérieure.

Lire un exemple ancien impose donc deux précautions à la fois : ne pas réécrire son vocabulaire comme s’il avait été produit aujourd’hui, et ne pas prendre ce vocabulaire ancien pour la définition présente d’un espace d’expérimentation libre.

La pile ainsi préservée reste un état à un instant donné. Elle peut aider à examiner un problème de transfert ; elle ne dit pas seule si l’opération suivante aurait réussi, quel chemin le message d’erreur a emprunté ou ce que le routeur aurait fait avec un autre paquet.

Il fallait d’abord savoir où commençait le supplément

L’objet MPLS dépend de RFC 4884, paru en avril 2007. Celui-ci organise des messages ICMP à plusieurs parties : la citation du datagramme initial est suivie d’un en-tête d’extension, puis d’un ou plusieurs objets.

La frontière exige une information explicite. Un attribut de huit bits, pris dans un espace auparavant réservé, indique la longueur de la zone citée. L’unité est un mot de 32 bits en IPv4 et de 64 bits en IPv6. Avec une extension, cette zone doit contenir au moins 128 octets, être complétée par des zéros si nécessaire et respecter l’alignement prévu.

Ces 128 octets sont un minimum dans le nouveau cadre. Ils étaient une position fixe pour certains logiciels déjà déployés. RFC 4884 rapporte que des implémentations produites entre 1999 et sa publication ajoutaient les extensions après exactement 128 octets, sans renseigner l’attribut de longueur.

Un expéditeur conforme pouvait désormais envoyer une citation plus longue. Pourtant, s’il souhaitait rester compris de ces lecteurs plus anciens, il devait conserver exactement 128 octets. Le bénéfice d’une information supplémentaire se heurtait à une hypothèse déjà installée dans les programmes.

Les applications classiques qui ne connaissent pas les extensions posent encore une autre question : elles peuvent prendre les nouveaux octets pour une continuation du datagramme cité. Le RFC en examine les effets connus. Il ne garantit pas que toute application ancienne soit indifférente à cette transformation.

Une compatibilité qu’il fallait choisir

La règle normale d’un lecteur conforme est stricte : une longueur nulle signifie qu’il n’y a pas d’extension. Cette interprétation laisse cependant de côté les messages anciens qui en portent une sans l’annoncer.

RFC 4884 demande donc aux traceroute conformes de proposer un mode de compatibilité non activé par défaut. Pour un message assez long dépourvu de longueur, ce mode cherche l’en-tête à l’ancienne position fixe et vérifie version et somme de contrôle.

Cette séparation évite de transformer toute lecture en devinette silencieuse. Le programme dispose d’une interprétation explicite et, à côté, d’un mode destiné à une pratique historique précise. Pour comprendre un résultat, il faut savoir lequel a été utilisé.

L’en-tête d’extension est de version 2. Sa somme de contrôle n’est pas une preuve cryptographique de provenance ; une valeur nulle indique d’ailleurs qu’aucune somme n’a été transmise. Les longueurs d’objets doivent être contrôlées. Un objet inconnu peut être ignoré sans rendre à lui seul l’ensemble du message malformé, mais une structure incorrecte ne doit pas être lue aveuglément.

La capacité de décoder une déclaration et la capacité d’en authentifier l’auteur restent deux choses distinctes.

Voir davantage dans une réponse n’en fait pas arriver une autre

Un traceroute enrichi peut afficher le contexte MPLS joint aux erreurs qu’il reçoit. Il n’obtient pas pour autant le pouvoir de susciter une réponse de tous les équipements traversés.

RFC 4950 le précise : les traitements de TTL qui mettent en échec le mécanisme de base de traceroute mettent aussi en échec sa version enrichie. L’extension ne redéfinit ni les conditions générales d’émission d’ICMP, ni tous les traitements propres aux encapsulations.

RFC 3443, de janvier 2003, distingue notamment le modèle Uniform, qui synchronise les TTL intérieur et extérieur aux limites du tunnel, des modèles Pipe dont le TTL extérieur peut partir d’une valeur indépendante. Un parcours peut ainsi ne pas provoquer les expirations internes attendues par une sonde jouant sur son TTL IP.

Cela ne veut dire ni que le TTL extérieur n’expire jamais, ni que toute forme d’ICMP devient impossible. Cela indique une limite de la méthode d’observation. Un format de rapport plus riche ne modifie pas automatiquement le phénomène qui déclenche le rapport.

L’opérateur peut aussi décider à qui montrer la pile. RFC 4950 évoque la destination du message ICMP, un réglage global ou la profondeur de pile comme critères possibles. Une adresse d’administration peut recevoir un supplément qui n’est pas envoyé à une adresse extérieure.

L’absence d’une ligne MPLS n’est donc pas un certificat d’absence de MPLS. Elle peut résulter de l’émission, du transport, de la politique de divulgation ou de la lecture. Le texte de 2007 disait le mécanisme déjà largement déployé ; cette appréciation historique n’est ni un recensement actuel ni la date d’un basculement mondial.

Le gain demeure précis : conserver une trace de ce qui arrivait avant que le traitement IP n’en efface l’enveloppe. Une trace supplémentaire n’abolit ni le trajet du rapport, ni la position de celui qui le lit.