Résumé

  • Uniform propage l’état de durée de vie à travers la frontière de labels et laisse visibles les LSR du tunnel depuis l’extérieur du LSP.
  • Pipe vise à présenter le tunnel comme un seul saut ; Short Pipe se distingue à la sortie, où le paquet transporté reçoit le traitement d’un saut de transfert ordinaire.
  • Le RFC 3443 ne définit aucun mécanisme de signalisation du modèle. L’opérateur le sélectionne par configuration ou interface de gestion, et les contrôles usuels de décrément et d’abandon continuent de s’appliquer.

Le mécanisme commence par une décision locale, et non par une négociation entre pairs. À l’entrée, un push de label suit le modèle choisi. Les LSR de transit effectuent les swaps et traitent l’état TTL concerné. À la sortie, un pop — éventuellement un PHP, c’est-à-dire une suppression par le routeur pénultième — doit produire le traitement prévu. Le RFC 3032 fournit le contexte d’encodage de la pile de labels. Le RFC 3270 apporte un contexte opérationnel MPLS lié aux services différenciés ; aucun des deux ne transforme le TTL en autorisation de route ou en authentification de pair.

Avec Uniform, l’état TTL MPLS et celui du paquet transporté sont propagés à travers la frontière de labels. Les LSR intermédiaires restent ainsi visibles pour le trafic observé hors du tunnel, sous réserve de la mise en œuvre et du chemin effectivement suivi.

Pipe propose une abstraction inverse : le tunnel est destiné à apparaître comme un seul saut, quel que soit le nombre de LSR traversés. Lors d’un push Pipe ou Short Pipe, le TTL du nouveau label est une valeur configurée par l’opérateur ; il n’est pas copié depuis l’en-tête situé dessous. Le RFC 3443 indique que de nombreuses implémentations utilisaient 255 à l’époque de sa publication. Cela décrit une tendance historique, pas une obligation universelle.

Short Pipe diffère au point de sortie. L’en-tête du paquet transporté est traité comme si la sortie du tunnel était un saut ordinaire, avec le décrément prévu. Le RFC décrit un décrément de bout en bout équivalent avec ou sans PHP lorsque les procédures sont correctement appliquées. La règle générale reste déterminante : le TTL sortant vaut normalement le TTL entrant moins un, et le paquet n’est pas transmis si le contrôle du TTL sortant échoue.

Le risque de correction se concentre aux frontières. Un PHP peut retirer le label supérieur avant que l’équipement suivant n’effectue l’opération attendue par le modèle. Une pile hiérarchique ajoute d’autres frontières : les labels internes et externes doivent recevoir le push, swap ou pop approprié. Une mise en œuvre partielle ou incohérente peut donc produire une expiration, une visibilité ou un résultat de traceroute inattendu sans que la configuration déclarée ait changé. L’absence d’un saut interne ne prouve ni Pipe ni Short Pipe, ni le chemin emprunté, ni la cohérence de tous les équipements.

Un dispositif de vérification concret doit comparer le même flux contrôlé avec chaque modèle, consigner le TTL initial poussé, examiner la profondeur de pile et les opérations à l’entrée, en transit et à la sortie, puis observer le TTL du paquet avant et après PHP. Il faut inclure une sonde à TTL faible destinée à échouer au contrôle prévu, un cas de pile à plusieurs labels et une comparaison avec PHP activé et désactivé lorsque l’environnement permet ce test. Ce sont des cas de vérification, non des seuils obligatoires ni des commandes de constructeur.

Le chemin de décision est le suivant : déterminer d’abord si la visibilité interne est nécessaire à l’exploitation ; choisir ensuite Uniform, Pipe ou Short Pipe ; consigner la valeur TTL configurée sans supposer 255 ; vérifier push, swap, pop et PHP à chaque frontière ; tester l’expiration et les piles multiples ; enfin documenter ce qu’un observateur externe peut conclure. Le modèle ne contrôle que la propagation du TTL et la visibilité. Il n’établit pas de LSP, n’autorise pas une route, n’authentifie pas un point terminal ou un pair, n’accorde pas d’accès, ne modifie pas la politique de transfert et ne chiffre pas le trafic.

Les RFC ne donnent ni la prévalence actuelle des modèles, ni une valeur par défaut universelle des constructeurs, ni un taux mesuré de réduction des incidents, ni une politique universelle pour masquer ou exposer les sauts. Le RFC 3443 précise également que sa clarification n’introduit pas de nouveaux problèmes de sécurité au-delà des spécifications MPLS citées.

Sources