Résumé

  • RFC 3609 fait du détail d’un tunnel une information conditionnelle: un saut IP extérieur peut être exact tout en masquant plusieurs sauts inférieurs, imbriqués ou hétérogènes.
  • Une trace défendable doit conserver l’autorisation, le plan interrogé, l’équivalence de la sonde, chaque couple requête-réponse et la cause d’une absence; elle ne prouve ni propriété, ni livraison, ni résultat utilisateur.

La transparence n’est pas un état par défaut

Deux écrans peuvent décrire le même instant sans montrer la même profondeur. Le premier présente une entrée et une sortie reliées par un seul saut. Le second déplie un tunnel, nomme son type, ses extrémités et plusieurs composants. Il serait tentant de qualifier le premier d’incomplet et le second de vérité. RFC 3609 impose une lecture plus rigoureuse: le niveau de détail est demandé par l’utilisateur, fourni si la politique l’autorise et borné par les capacités effectivement présentes.

Publié en septembre 2003 dans la catégorie Informational, le document définit des exigences pour une application de traçage générique et pour un protocole qui la soutiendrait. Il ne normalise pas à lui seul un protocole universel, n’atteste aucun déploiement et ne transforme pas la liste GRE, MPLS, IPsec, GMPLS, IP-in-IP ou L2TP en inventaire d’un réseau réel. Sa valeur est architecturale: il explique pourquoi tracer la couche IP ne suffit pas toujours à vérifier le plan de transfert qui la porte.

Le saut visible au niveau supérieur et le saut inférieur contenu dans un tunnel sont deux objets de preuve. Le premier appartient à l’abstraction IP. Le second cherche à décomposer un mécanisme de transport caché. Une entrée et une sortie observées ne décrivent pas automatiquement le chemin intérieur. Un détail fourni par le plan de contrôle ne démontre pas davantage qu’un paquet de production a suivi chaque élément annoncé.

Le droit de voir accompagne la réponse

RFC 3609 prévoit un jeton de sécurité associé à la demande. Les équipements s’en servent pour évaluer les privilèges du demandeur et décider quelles informations rendre. Une politique configurable doit couvrir identification, autorisation et maîtrise des ressources. Autrement dit, la topologie révélée n’est pas seulement une donnée technique; c’est une réponse produite dans une relation d’autorité.

Cette condition doit rester attachée au résultat. Si une équipe exporte une trace privilégiée dans un rapport sans conserver le niveau d’accès, le lecteur peut croire que la même information est observable depuis n’importe quel point. Si une vue publique masque l’intérieur, le silence ne prouve pas l’absence de tunnel. Le champ correct n’est donc pas «tunnel: oui/non», mais «vue demandée, autorité, décision de divulgation, profondeur obtenue et heure».

Le document souhaite qu’une vue détaillée puisse indiquer type, nom, identifiant, adresses d’extrémité, composants et délai aller-retour. Ces attributs ont chacun une portée limitée. Un nom ne garantit pas le propriétaire actuel. Un identifiant ne certifie pas la configuration en vigueur. Un délai aller-retour ne décrit pas séparément les deux directions. Une suite de composants observée à un instant ne garantit pas le trajet du prochain flux.

Une panne ne doit pas effacer les preuves précédentes

Le traçage devait rester utile à travers un chemin ou un tunnel rompu. D’où le modèle d’une sonde distincte et d’une réponse distincte pour chaque saut. Si un message unique devait parcourir tout le trajet et accumuler les contributions, la rupture précisément recherchée détruirait la fin du témoignage. Des reçus séparés laissent une dernière limite connue.

Ce choix rend aussi les réponses négatives plus honnêtes. L’absence d’une réponse peut signaler un échec de transfert, un filtrage, une limitation de débit, un équipement qui ne prend pas en charge le protocole, une route de retour manquante ou un refus de divulgation. RFC 3609 demande à l’application d’indiquer un équipement non compatible et de tenter de reprendre l’exploration plus loin. «Non pris en charge», «non autorisé», «injoignable» et «inconnu» ne doivent jamais devenir un même voyant rouge.

La route de retour fait partie des conditions expérimentales. La machine de traçage doit atteindre l’entrée du chemin et l’entrée de chaque tunnel détaillé. Les équipements intérieurs doivent pouvoir revenir vers l’entrée du tunnel, pas nécessairement directement vers l’observateur. Un service peut donc continuer à transporter du trafic alors que la chaîne diagnostique ne sait plus rapporter ses observations. Cette divergence est un incident d’observabilité possible, pas la preuve automatique d’une panne de transfert.

La sonde peut fabriquer son propre trajet

Le RFC écarte l’idée d’une sonde unique portant l’option IP Router Alert. De nombreux réseaux ne traitent pas les paquets avec options comme les autres. La sonde aurait alors observé une route créée par sa propre singularité, et non celle du trafic que l’opérateur voulait comprendre.

Le problème dépasse cette option. Taille, famille d’adresses, clé de flux, marquage, encapsulation et calendrier peuvent modifier la classification. Une trace ne devient représentative qu’après avoir documenté le spécimen testé et expliqué pourquoi son traitement correspond au trafic concerné. Ajouter davantage de détails à une classe de paquets différente augmente la précision d’une mauvaise comparaison.

RFC 3609 préfère des échanges sans état transportés par UDP, notamment pour l’échelle et la résistance au déni de service. «Sans état» signifie que les nœuds ne doivent pas conserver une session entre les messages successifs. Cela ne rend pas une réponse vraie par construction, n’authentifie pas la topologie et ne prouve pas que le plan de transfert a livré l’application.

Deux plans, deux témoins

L’application souhaitée devait interroger le plan de contrôle, le plan de transfert ou les deux. Dans le premier cas, l’équipement d’entrée du saut rapporte ses détails. Dans le second, l’équipement de sortie témoigne lorsque le tunnel offre un mécanisme comparable à la décrémentation du TTL. Le lieu d’énonciation change donc avec le type de trace.

Un plan de contrôle cohérent peut coexister avec une programmation de transfert obsolète. Une observation du plan de transfert peut montrer le passage d’une sonde sans expliquer la politique qui l’a sélectionné. Leur concordance renforce l’analyse; elle ne fusionne pas les deux comptes. Il faut conserver séparément intention, état programmé, comportement observé et résultat du service.

Les normes ultérieures éclairent ce découpage. GRE et MPLS décrivent des couches qui peuvent cacher ou transformer la visibilité IP. Le traitement du TTL MPLS montre que propagation et visibilité ne sont pas synonymes. Les mécanismes de ping et traceroute LSP, repris dans RFC 8029 après RFC 4379, définissent leurs propres validations. RFC 4884 et RFC 4950 permettent d’ajouter des objets aux messages ICMP. Chaque mécanisme enrichit la preuve; aucun ne convertit une réponse locale en autorité absolue sur le chemin.

Une chaîne minimale de reçus

Un dossier exploitable commence par le paquet de référence: origine, destination, champs de flux, taille, options, marquage et heure. Il ajoute ensuite la trace extérieure, le point d’observation et la méthode. Lorsqu’un tunnel apparaît, il enregistre entrée, sortie, profondeur demandée, autorisation et plan interrogé. Les sauts internes gardent leurs couples sonde-réponse, leurs conditions de retour et leurs états négatifs. La livraison et le résultat applicatif restent enfin des reçus indépendants.

Cette architecture respecte un principe simple: le minimum commun doit rendre les observations comparables sans abolir l’autonomie locale. Un réseau peut protéger les détails sensibles et néanmoins décrire clairement ce qu’il a fourni ou refusé. Le code en fonctionnement produit l’état; la trace n’en est qu’une projection datée.

Sources