Résumé

  • RFC 9573 remplace une multitude d’interprétations propres aux PE d’entrée par des labels communs issus d’un bloc de domaine ou de quelques espaces contextuels.
  • L’économie repose sur une condition externe : tous les PE et points de segmentation concernés doivent comprendre la procédure et connaître la même affectation.
  • La preuve exploitable doit relier l’autorité d’allocation, la version de configuration, la réservation locale, la bonne table MPLS, l’installation effective et le trafic observé.

La maintenance était terminée, sauf sur un PE

À minuit, le contrôleur attribue le label 1407 à un nouveau domaine de diffusion. Vingt-neuf PE accusent réception. Le trentième redémarre sur une ancienne configuration où 1407 désigne encore un autre service. Au matin, le plan de contrôle affiche le même nombre partout. Il ne fournit pas, à lui seul, la preuve du même sens.

C’est précisément la frontière de RFC 9573. Le document part d’un problème d’échelle : dans le modèle amont classique, le PE de sortie interprète le label dans l’espace propre au PE d’entrée. Avec 1 001 PE et 1 000 VPN ou BD par PE, l’exemple du RFC conduit chaque sortie à pouvoir comprendre un million de labels répartis dans mille contextes.

Une autorité centrale peut au contraire attribuer un label identique à un VPN, un BD ou un segment Ethernet. Le gain est considérable. Mais l’identité de l’émetteur n’est plus la clé qui sépare naturellement les significations. La cohérence dépend désormais de la distribution d’une convention commune.

Le standard exige l’accord sans normaliser sa fabrication

RFC 9573 dit deux choses qu’il faut lire ensemble. Tous les PE et points de segmentation doivent prendre en charge la procédure lorsqu’elle est employée. La manière de garantir ce support reste hors périmètre. De même, l’affectation du label et la connaissance de cette affectation par chaque membre sont obtenues par des méthodes externes au document.

Le drapeau DCB ne remplace pas cette preuve. Il indique que le label annoncé appartient au bloc commun réservé. Il ne démontre ni que tous les équipements ont réservé ce bloc, ni que la même révision de configuration est active, ni que la table de transfert contient l’entrée voulue.

Le contrat d’exploitation doit donc nommer le domaine réel, sa population, sa version et son autorité. « Commun » ne signifie pas mondial ; RFC 9573 définit même le domaine de façon souple, autour des routeurs qui partagent le bloc.

Deux labels, deux liaisons à conserver

Quand le bloc commun ne peut contenir tous les services, un label DCB plus petit peut sélectionner un espace de labels contextuel. Le paquet porte alors le label du service, puis le label qui indique dans quelle table ce service doit être recherché.

Cette indirection ne supprime pas l’état. Elle sépare la liaison « sélecteur vers table » de la liaison « label interne vers service ». Le PE de réception installe la première dans sa table MPLS par défaut et la seconde dans la table choisie. Une seule liaison périmée suffit pour acheminer correctement vers la mauvaise destination logique.

L’Extended Community d’identification rend le contexte transportable. Elle n’embarque pas l’historique d’approbation, la génération du contrôleur ou l’accusé de programmation matériel. Ces éléments doivent rester disponibles ailleurs et pouvoir être rapprochés d’un paquet ou d’une anomalie.

La segmentation remet de la localité dans l’allocation

Deux flux peuvent partager un tunnel sélectif dans une région et emprunter deux tunnels différents dans la suivante. Le point de segmentation ne peut alors se contenter d’un unique label de VPN. Il doit distinguer les PMSI afin de commuter chaque flux vers le bon segment aval.

RFC 9573 prévoit des blocs disjoints attribués aux PE dans quelques espaces contextuels. Chaque PE alloue localement ses labels de PMSI segmentés dans son bloc. L’autorité centrale ne choisit plus chaque valeur, mais elle doit encore garantir l’absence de chevauchement, l’appartenance du bloc et son cycle de réutilisation.

Une autre option effectue des recherches de flux dans des VRF au point de segmentation. Elle échange l’échelle des labels contre l’échelle des routes (C-S,C-G). Le choix architectural ne doit donc pas être présenté comme une disparition de complexité : il déplace l’endroit où celle-ci est stockée et vérifiée.

Face à l’ambiguïté, le routeur retire la route

Le RFC interdit de joindre à la même route le drapeau DCB et l’identifiant d’espace contextuel. Les deux ensemble entraînent un traitement comme retrait. Sans aucun des deux, le label conserve l’interprétation amont propre au PE source selon les procédures antérieures.

Plusieurs routes x-PMSI ou IMET utilisant le même tunnel doivent également adopter un régime cohérent. Mélanger les modes rend impossible l’interprétation sûre du label suivant l’encapsulation et provoque le retrait logique des routes concernées.

Cette règle ferme une ambiguïté du plan de contrôle. Elle ne certifie pas la purge immédiate du plan de données. Il faut encore observer la suppression des anciennes entrées, l’arrêt du trafic sous l’ancien sens et l’absence de livraison croisée.

Une attribution IANA ne vaut pas déploiement

RFC 9573 enregistre le bit DCB, le sous-type de l’Extended Community et le registre des types d’identifiant. Ces numéros stabilisent la syntaxe. Ils ne prouvent ni le support d’un logiciel, ni l’activation d’un domaine, ni la correction d’un contrôleur.

Le texte ne revendique pas non plus une nouvelle vulnérabilité. Il estime que les méthodes d’allocation n’ajoutent pas de nouveau problème de sécurité aux bases citées. Il serait donc abusif de transformer une dépendance de coordination en récit d’attaque. La conclusion plus rigoureuse est opérationnelle : le paquet ne contient pas la preuve de l’accord qui donne son sens au label.

Sources

Sources