Stateless Ingress : Orchestration des tunnels locaux-vers-cloud via IPv6 Segment Routing (SRv6)

Les proxies d’extrémité stateful sont le principal goulot d’étranglement pour le tunneling à haut débit. IPv6 Segment Routing (SRv6) intègre la logique de routage directement dans l’en-tête du paquet, éliminant complètement le goulot d’étranglement dû à l’état en périphérie.

---

Le point critique de l’informatique en périphérie

Dans les architectures distribuées modernes, le périmètre réseau est devenu extrêmement complexe — chargé de reverse proxies, équilibreurs de charge, passerelles NAT et pare-feux avec état. Lorsqu’un paquet arrive à la frontière du cloud destiné à un environnement de développement local, à un microservice interne ou à un appareil sur site, un contrôleur d’entrée centralisé doit l’intercepter, terminer la connexion, consulter une base de données d’état de routage ou une table en mémoire, puis réencapsuler la charge utile dans un tunnel.

Ce traitement avec état a été la pierre angulaire de la livraison du trafic web depuis plus d’une décennie. Mais il devient un point critique fatal sous des exigences de haut débit et de latence ultra-faible. Le coût computationnel de la gestion des tables d’état limite la scalabilité et augmente la latence par paquet.

SRv6 bouleverse fondamentalement ce paradigme. Standardisé par l’IETF sous la forme de RFC 8986 en février 2021, le cadre de programmation réseau SRv6 permet à un opérateur ou une application de spécifier un programme de traitement de paquets en encodant une séquence d’instructions directement dans l’en-tête IPv6. Chaque instruction est identifiée par un Segment Identifier (SID) SRv6 et exécutée sur un ou plusieurs nœuds du réseau — sans besoin d’une machine d’état centralisée.

Au lieu de dépendre d’un appareil middleware monolithique pour suivre chaque tunnel et flux actifs, le nœud d’en-tête SR intègre des instructions de routage explicites — appelées segments — directement dans l’en-tête IPv6. Les routeurs de transit n’ont jamais besoin de connaître les tunnels ; ils exécutent simplement les instructions de l’en-tête en séquence à la vitesse matérielle. En déplaçant l’état hors de l’appareil et dans le paquet lui-même, les architectes réalisent un ingress réseau sans état véritable.

---

Le goulot d’étranglement des proxies avec état en environnements à haut débit

Pour apprécier pleinement la valeur de SRv6, considérons ce que coûte réellement un ingress avec état à grande échelle. Des outils comme Nginx, HAProxy, Envoy ou des ADC matériels se trouvent en périphérie du cloud. Lorsqu’un paquet entrant arrive, le proxy doit effectuer une recherche à 5-tuple (IP source, IP destination, port source, port destination, protocole) dans une table d’état de connexion pour déterminer à quel tunnel appartient le paquet.

Maintenir cet état est coûteux. À mesure que le nombre de tunnels concurrents atteint des dizaines ou centaines de milliers, les tables d’état grossissent en conséquence. Le proxy doit suivre en permanence l’état des connexions TCP — SYN, ESTABLISHED, FIN, WAIT — gérer la récupération de mémoire pour les connexions abandonnées, et gérer les allocations de buffer pour des tailles MTU variables.

L’architecture en étoile oblige aussi le trafic à passer par un point d’inspection centralisé, ce qui empêche une routage en chemin le plus court dans le tissu réseau. Chaque paquet doit faire un détour par le load balancer avant d’atteindre sa destination — phénomène appelé tromboning — ajoutant de la latence et limitant le débit, ce qui est particulièrement dommageable pour les pipelines de données en temps réel.

---

La mécanique de la programmation réseau SRv6

La solution réside dans la programmabilité native de IPv6. SRv6 exploite l’espace d’adressage IPv6 128 bits pour encoder non seulement les points de terminaison réseau, mais aussi des opérations de forwarding spécifiques.

Dans un réseau activé SRv6, une adresse IPv6 est réutilisée comme un Segment Identifier (SID). Tel que défini dans RFC 8986 (Section 3.1), un SID SRv6 standard de 128 bits est structuré en trois composants logiques :

Locator (B:N) : Les bits les plus significatifs représentant l’adresse réseau du nœud compatible SRv6. Il est routé nativement via les protocoles de routage intérieur standards — IS-IS ou OSPFv3 — avec extensions SRv6. Le locator s’écrit sous la forme B:N où B est le bloc de SID SRv6 attribué par l’opérateur et N identifie le nœud spécifique.

Fonction : Un identifiant unique pour l’opération précise que le nœud cible doit effectuer lorsque le paquet arrive.

Argument (ARG) : Métadonnées optionnelles passées à la fonction, permettant une variation comportementale à la destination sans signalisation supplémentaire.

Lorsqu’un paquet arrive en périphérie du réseau, le nœud d’en-tête SR encapsule celui-ci avec un en-tête d’extension IPv6 spécialisé appelé Segment Routing Header (SRH), standardisé dans RFC 8754 (mars 2020). Cet en-tête transporte une liste ordonnée de SIDs. Au fur et à mesure du transit dans le réseau, chaque nœud compatible SRv6 inspecte le SID actif. Si le Locator correspond au bloc de locator configuré sur le nœud, celui-ci exécute la Fonction correspondante.

RFC 8986 définit un ensemble de comportements d’endpoints standardisés, parmi lesquels :

• End : La fonction de transit fondamentale. Le nœud décrémente le compteur Segments Left, met à jour l’adresse IPv6 de destination avec le prochain SID de la liste, et forwarde selon une recherche dans la FIB IGP contre la nouvelle DA.
• End.X : Met à jour le segment actif et connecte explicitement le paquet à une adjacency Layer 3 spécifique — essentiel pour l’ingénierie du trafic avec contraintes de chemin strict.
• End.DX4 / End.DX6 : Le nœud décapsule l’en-tête IPv6 externe et forwarde la charge utile IPv4 ou IPv6 interne vers le prochain saut spécifié. C’est la fonction clé pour livrer directement le trafic tunnelé à une terminaison locale.
• H.Encaps (Headend Encapsulation) : Un comportement d’entrée qui enveloppe un paquet IP entrant dans un en-tête IPv6 externe avec un SRH contenant la liste complète de segments. C’est la fonction appliquée à l’extrémité d’entrée sans état.

---

Réaliser un ingress sans état : éliminer le middleware

En chaînant ces comportements, les architectes peuvent déployer un modèle d’entrée qui ne demande aucun état par flux à l’extrémité du réseau.

Le nœud d’en-tête SR reçoit un paquet entrant depuis Internet ou un partenaire de peering. Plutôt que de terminer la connexion TCP ou de consulter une table d’état, le nœud d’entrée effectue une correspondance de politique unique, accélérée matériellement — généralement distribuée via BGP — et applique immédiatement H.Encaps. La charge utile est enveloppée dans un en-tête IPv6 portant la liste SID précise nécessaire pour atteindre la terminaison cible.

Les routeurs de transit dans le cœur du réseau n’ont aucune connaissance des tunnels, aucune état de connexion à maintenir, et aucune entrée par flux à mettre à jour. Ils regardent simplement l’adresse IPv6 de destination active et forwardent selon le chemin le plus court dans l’IGP. L’état par flux est totalement éliminé du cœur.

Au nœud terminal — un routeur d’extrémité fournisseur, une passerelle sur site ou une station de travail de développeur utilisant une pile réseau SRv6 — la fonction End.DX4 ou End.DX6 décapsule l’IPv6 externe et le SRH, livrant la charge utile originale directement à la socket de l’application locale.

Implémentations open-source

Deux stacks open-source de niveau production rendent SRv6 accessible pour les travaux en laboratoire et les déploiements SDN :

Noyau Linux : La prise en charge de SRv6 a été introduite dans le noyau 4.10 (encapsulation) et étendue avec les comportements seg6local dans le noyau 4.14. La suite d’outils iproute2 expose SRv6 via encap seg6 (routage source) et encap seg6local (fonctions d’endpoint). Le noyau Linux supporte désormais la plupart des comportements RFC 8986 et intègre SRv6 avec eBPF, Netfilter, FRRouting, Cilium et SONiC.

FD.io VPP (Vector Packet Processing) : La mise en œuvre SRv6 de VPP supporte l’ensemble complet des comportements RFC 8986 LocalSID — End, End.X, End.DX4, End.DX6, End.DT4, End.DT6, End.DX2, et plus — ainsi que le steering SR Policy avec T.Insert et T.Encaps. VPP traite les paquets en vecteurs via sa couche de traitement DPDK, atteignant des débits comparables au matériel en logiciel.

---

Ingénierie du trafic, Flex-Algo et compression uSID

Remplacer RSVP-TE par le routage source

L’ingénierie du trafic legacy dépendait de RSVP-TE (Resource Reservation Protocol — Traffic Engineering, RFC 3209), un protocole de signalisation avec état nécessitant que chaque routeur en chemin réserve activement la bande passante et maintienne l’état du tunnel. À grande échelle, la surcharge de contrôle de RSVP-TE cause une forte charge CPU sur les routeurs centraux.

SRv6 réalise la même ingénierie du trafic granulaire de manière sans état via le routage source. Le nœud d’en-tête SR dicte tout le chemin de forwarding en empilant des SIDs dans le SRH. Les routeurs centraux ne portent aucune information de signalisation. Pour optimiser davantage, les déploiements modernes SRv6 utilisent Flex-Algo, standardisé dans RFC 9350 (février 2023, Standards Track).

Flex-Algo permet aux opérateurs de calculer plusieurs topologies de routage logiques sur la même infrastructure physique en définissant des algorithmes contraints. Comme spécifié dans RFC 9350, dans SRv6 c’est le locator — et non le SID — qui lie à l’algorithme. Un nœud est provisionné avec un locator distinct pour chaque paire (topologie, algorithme) qu’il supporte. Par exemple :

• L’algorithme 128 peut calculer des chemins strictement optimisés pour une latence minimale.
• L’algorithme 129 peut calculer des chemins excluant des liens correspondant à une couleur de groupe administratif spécifique.

Lorsqu’un nœud d’entrée sans état encapsule un paquet, il sélectionne le bloc de locator associé à l’algorithme Flex-Algo désiré, garantissant que le trafic critique suit le chemin conforme aux contraintes sans nécessiter de re-signalisation centralisée des changements d’état dans le réseau.

Surmonter la surcharge d’en-tête avec RFC 9800 (uSID)

L’un des vrais défis des premiers déploiements SRv6 était la surcharge d’encapsulation. Chaque SID est une adresse IPv6 complète de 128 bits. Selon la documentation de Huawei sur la structure SRH, la longueur du SRH est (n × 16 + 8) octets, où n est le nombre de segments. Un chemin de 6 sauts nécessite 104 octets de SRH seul — ajoutés au-dessus de l’en-tête IPv6 standard de 40 octets. Pour des chemins avec contraintes explicites hop-by-hop, cette surcharge peut pousser les paquets vers la fragmentation MTU et dégrader le débit ASIC matériel sur certaines plateformes.

La solution est l’encodage compressé de la liste de segments SRv6 (RFC 9800), publié officiellement comme RFC 9800 (Standards Track, juin 2025), qui met à jour RFC 8754. RFC 9800 définit les comportements d’endpoint NEXT-CSID et REPLACE-CSID, déployés couramment sous la forme d’une architecture micro-SID (uSID).

Au lieu d’un SID séparé de 128 bits par saut, RFC 9800 compacte plusieurs C-SID (Compressed SID) dans un seul conteneur de 128 bits. Avec un bloc locator de 32 bits (GIB) et des C-SID de 16 bits, un seul conteneur de 128 bits peut transporter jusqu’à six instructions de forwarding distinctes. La mécanique de traitement principale est « décalage et recherche » : lorsqu’un nœud traite son C-SID, il décale les C-SID restantes dans le conteneur et effectue une recherche FIB sur le suivant — éliminant la nécessité de décrémenter Segments Left pour chaque micro-segment.

Critiquement, la compression uSID est transparente pour les nœuds de transit non SRv6, qui ne voient qu’une adresse IPv6 de destination standard. Cela permet un déploiement progressif : seuls les endpoints compatibles SRv6 doivent supporter l’encodage compressé, tandis que le reste du réseau forwarde avec IPv6 standard.

L’interopérabilité multi-fournisseurs pour uSID a été validée par le European Advanced Networking Test Center (EANTC) en 2023, avec la participation d’Arista, Arrcus, Cisco, Huawei, Juniper, Nokia, Keysight et Spirent. Les tests EANTC 2024 ont spécifiquement porté sur les scénarios Micro-SID uSID.

---

Stratégies de migration et environnements mixtes

La transition d’une architecture d’entrée legacy vers SRv6 nécessite une ingénierie délibérée, notamment lorsque des endpoints non SRv6 existent encore.

Tous les workloads de destination ne peuvent pas traiter les en-têtes SRv6. Pour ces endpoints, un proxy local se place juste devant le workload legacy, agissant comme le dernier endpoint de segment SRv6. Il termine la liste de segments, décapsule l’IPv6 et le SRH, et forwarde le trafic IP non encapsulé vers l’application. Bien que cela introduise techniquement un proxy, cela limite l’état à l’extrémité locale — les grandes tables d’état centralisées en entrée du cloud sont toujours éliminées.

Pour la coexistence SR-MPLS/SRv6, un SID de liaison au niveau de la passerelle du domaine mappe une politique SRv6 entière à une seule étiquette MPLS, permettant une intégration transparente : le domaine A (SR-MPLS) se termine à la passerelle, qui ré-encapsule dans le domaine SRv6 pour la livraison ultérieure. BGP peut signaler simultanément des SIDs SR-MPLS et SRv6 pour le même préfixe VPN, permettant à la passerelle de gérer la traduction.

Du point de vue du contrôle, SRv6 simplifie les opérations. Au lieu de faire fonctionner RSVP-TE ou LDP avec un IGP, un réseau SRv6 fonctionne généralement avec un cœur sans BGP, s’appuyant sur IS-IS ou OSPFv3 avec extensions SRv6 pour distribuer les blocs de locator. BGP Link-State (BGP-LS) exporte la topologie vers un PCE, qui calcule des listes de segments optimisées et les distribue aux nœuds d’en-tête SR à la demande via PCEP ou BGP SR-Policy (RFC 9256).

Considérations de sécurité

Le modèle de sécurité SRv6 diffère fondamentalement de MPLS. Les étiquettes MPLS sont locales et non routables, limitant l’exposition de la topologie. Les SIDs SRv6 sont des adresses IPv6 routables globalement, rendant la topologie du domaine potentiellement visible à des attaquants externes si les préfixes SID ne sont pas filtrés correctement aux frontières du domaine. RFC 8754 (Section 5) définit le modèle de sécurité du domaine SR : la déploiement le plus courant repose sur un filtrage iACL à l’entrée du domaine pour rejeter les paquets portant un SRH de type Routing 4 provenant de sources non fiables, combiné à uRPF pour rejeter les paquets avec des adresses source usurpées.

RFC 9602 (octobre 2024) alloue un préfixe IPv6 dédié pour les SIDs SRv6 et indique que les déploiements n’utilisant pas ce préfixe doivent faire preuve d’une vigilance accrue pour éviter la fuite de paquets SRv6 à travers les frontières du domaine. La proposition de l’IETF draft-ietf-spring-srv6-security (actuellement à la révision 14 début 2026) fournit une catégorisation détaillée des menaces et des mesures d’atténuation.

---

Maturité de l’écosystème et déploiements en production

SRv6 a dépassé le stade de l’adoption précoce. Les déploiements en production couvrent plusieurs continents et cas d’usage :

Télécoms et opérateurs : SoftBank (Japon) a déployé SRv6 pour le slicing 5G, créant des chemins réseau isolés et contraints pour des services spécifiques. Bell Canada a déployé SRv6 avec uSID sur son backbone, avec une interopérabilité multivendor démontrée en 2023 entre Cisco, Nokia et Juniper. China Unicom et China Telecom ont tous deux déployé SRv6 à grande échelle sur leurs backbones nationaux.

Hyperscalers : Microsoft a présenté SRv6 comme une technologie clé pour ses réseaux backend IA à grande échelle lors du OCP 2025, notamment pour son déploiement Azure Fairwater DC. Alibaba et Microsoft ont contribué aux améliorations SRv6 uSID dans le système d’exploitation réseau SONiC, permettant aux hyperscalers d’intégrer SRv6 dans leurs fabrics SDN. Reliance Jio, en partenariat avec Cisco, déploie SRv6 dans son réseau pour couvrir 100 millions de foyers et 600 millions de clients mobiles et entreprises.

Support plateforme matérielle : Des implémentations SRv6 en production existent sur Cisco ASR 9000/NCS 5500/NCS 540 (IOS XR), Cisco Nexus (NX-OS), Huawei NE40E/NE5000E/NE8000 (VRP), Juniper MX/PTX, Nokia 7750 SR, Arista 7280R3, et plateformes Arrcus ArcOS. FRRouting (FRR) 10.5 a ajouté des fonctionnalités clés SRv6 uSID, notamment support multi-locator, format F4816, et attribution de locator SRv6 par VRF.

---

Conclusion

Le passage d’un middleware avec état à un routage sans état, basé sur les paquets, marque une étape fondamentale dans l’évolution du réseau. À mesure que les architectures distribuées deviennent plus complexes et que le volume de télémétrie local-vers-cloud augmente, le périmètre réseau ne peut plus fonctionner comme une machine d’état centralisée à grande échelle.

SRv6 — standardisé par RFC 8754, RFC 8986, RFC 9350 et plus récemment RFC 9800 — fournit tous les outils : encapsulation sans état à l’en-tête, forwarding contraint via Flex-Algo, et compression d’en-tête efficace avec uSID. Le plan de contrôle se simplifie en un cœur sans BGP, utilisant IS-IS ou OSPFv3 avec extensions SRv6, avec une optimisation de chemin basée sur PCE via BGP-LS.

Les conditions pratiques sont réelles et doivent être reconnues : SRv6 nécessite une infrastructure IPv6 sur tout le domaine SR, la surcharge SRH reste une contrainte de conception sur les plateformes sans support uSID, et la sécurité aux frontières du domaine exige une configuration disciplinée d’ACL et uRPF. Mais l’écosystème a avancé. Le support matériel en ligne à pleine vitesse est en cours de déploiement chez tous les grands fournisseurs. Les hyperscalers l’adoptent à l’échelle de l’IA. La pile de standards IETF est complète. Pour les ingénieurs construisant aujourd’hui une infrastructure de tunnels local-vers-cloud, SRv6 n’est plus une technologie du futur — c’est un choix architectural de production.

---

Carte de référence

RFC	Titre	Statut	Date
RFC 8402	Architecture de Segment Routing	Standards Track	juillet 2018
RFC 8754	En-tête de Segment Routing IPv6 (SRH)	Standards Track	mars 2020
RFC 8986	Programmation réseau SRv6	Standards Track	février 2021
RFC 9256	Architecture de politique de routage par segments	Standards Track	juillet 2022
RFC 9259	OAM dans SRv6	Standards Track	juin 2022
RFC 9350	Algorithme flexible IGP	Standards Track	février 2023
RFC 9602	SIDs SRv6 dans l’architecture d’adressage IPv6	Informationnel	octobre 2024
RFC 9800	Encodage compressé de la liste de segments SRv6	Standards Track	juin 2025

---

Historique des modifications

Vérification factuelle par rapport aux sources en direct (juin 2026) :

• Date RFC 8986 corrigée : article indiquait aucune date ; confirmée février 2021 (Standards Track, IETF).
• RFC 8754 ajoutée : la spécification SRH (RFC 8754, mars 2020) manquait dans l’original et est fondamentale ; ajoutée partout.
• Formule de surcharge SRH corrigée : l’article original indiquait « 8 sauts ajouteraient 128 octets. » La formule correcte est (n × 16) + 8 octets pour le SRH, donc 8 segments donnent un SRH de 136 octets (plus l’en-tête IPv6 de 40 octets). Corrigé selon la documentation technique de Huawei.
• Numéro RFC de uSID corrigé et mis à jour : l’article décrivait uSID de façon informelle sans référence RFC et laissait entendre qu’il était déjà standardisé dans RFC 8986. La compression uSID a été publiée comme RFC 9800 (Standards Track, juin 2025). Mise à jour pour refléter le bon RFC, le facteur de compression (jusqu’à 6 C-SID par conteneur de 128 bits avec GIB 32 bits et C-SID 16 bits selon srv6.md), et la transparence pour les nœuds de transit.
• Flex-Algo RFC ajouté : standardisé dans RFC 9350 (février 2023). Ajouté. Clarifié que dans SRv6 c’est le locator, pas le SID, qui lie à l’algorithme (Section 2 de RFC 9350).
• Version du noyau Linux corrigée : l’article original indiquait « Linux v4.10+ » supporte SRv6. Correct : le noyau 4.10 a introduit l’encapsulation SRv6 ; les comportements seg6local (nécessaires pour End.DX4 etc.) sont arrivés dans le noyau 4.14. Corrigé.
• Vérification de la prise en charge VPP : support SRv6 confirmé via la documentation fd.io ; liste précise des comportements (End, End.X, End.DX4, End.DX6, End.DT4, End.DT6, End.DX2, End.B6.Encaps).
• Suppression de la section NVIDIA Omniverse : la section initiale sur Omniverse « Industrial Mirroring » incluait des affirmations spécifiques non sourcées (par ex., un « pont local Omniverse » fonctionnant comme endpoint SRv6 natif). Aucun document technique vérifiable ne supporte cette présentation. La notion sous-jacente (SRv6 pour la télémétrie industrielle) est conservée mais les affirmations produits non sourcées sont supprimées.
• Ajout d’une section déploiements en production : SoftBank, Bell Canada, China Unicom, China Telecom, Azure, Alibaba, Reliance Jio, et l’écosystème SONiC, issus de drafts de déploiement IETF, Cisco, Nokia, segment-routing.net.
• Ajout de la section sécurité : les SIDs SRv6 sont routables globalement, contrairement aux étiquettes MPLS. La sécurité aux frontières du domaine (RFC 8754 Section 5, RFC 9602) et le travail en cours draft-ietf-spring-srv6-security (révision 14 début 2026) sont des considérations opérationnelles importantes.
• Ajout de RFC 9602 : publié en octobre 2024 — alloue un préfixe IPv6 dédié pour les SIDs SRv6 — pertinent pour l’adressage et la sécurité. Ajouté au tableau de référence.
• Ajout du tableau de référence RFCs : tous les RFCs cités listés avec statut et date de publication.
• Suppression des métadonnées / front matter : titre, hooks en gras, et métadonnées supprimés selon la convention de workflow.