Les cœurs de réseau d'entreprise à haut débit et les architectures maillées Anycast VPN nécessitent un pilotage agile des flux et une restauration de connectivité sous la seconde. Durant plus de deux décennies, la commutation d'étiquettes multiprotocole (MPLS) a constitué le socle standard de l'ingénierie de trafic et des réseaux privés virtuels de niveau 3 (L3VPN).

Toutefois, MPLS génère une complexité opérationnelle considérable. La gestion conjointe du protocole de distribution d'étiquettes (LDP), du protocole de réservation de ressources orienté trafic (RSVP-TE) et des sessions BGP ciblées contraint les routeurs de transit à conserver des milliers d'états dynamiques en mémoire matérielle.

Pour surmonter cette surcharge, l'IETF a formalisé le routage par segments sur IPv6 (SRv6) à travers les normes RFC 8402, RFC 8754 et RFC 8986. En unifiant le plan de contrôle et le plan de transfert directement au sein de paquets IPv6 natifs, SRv6 concrétise le routage à la source sans état, la programmabilité réseau et une tolérance aux pannes déterministe sous 50 millisecondes grâce à TI-LFA (Topology-Independent Loop-Free Alternate).

La crise de complexité de MPLS : la nécessité d'un plan de données IPv6 unifié

Les réseaux MPLS traditionnels dissocient la commutation d'étiquettes du routage IP sous-jacent. Dans les environnements multi-cloud modernes, cette scission crée des contraintes opérationnelles aiguës :

  1. Prolifération des protocoles : Les ingénieurs doivent déployer un protocole IGP (OSPF/IS-IS), LDP pour la liaison d'étiquettes, RSVP-TE pour la protection des tunnels et MP-BGP pour la diffusion des routes clientes.
  2. Saturation des états en transit : Avec RSVP-TE, chaque équipement intermédiaire conserve l'état individuel de chaque tunnel. Lorsque le maillage atteint des dizaines de milliers de liaisons, la mémoire des routeurs s'épuise et les temps de convergence explosent lors des pannes.
  3. Encapsulations hétérogènes : Les paquets MPLS ne peuvent transiter sur les réseaux IP publics sans tunnels d'encapsulation supplémentaires (GRE ou UDP), morcelant la télémétrie de bout en bout.

SRv6 remplace cet empilement hétérogène par un protocole universel unique : IPv6 standard. Les paquets transportent leurs propres instructions de guidage dans un en-tête d'extension compact, permettant aux commutateurs de traiter le trafic de transit par simple recherche du préfixe le plus long (LPM).

Architecture de programmation réseau SRv6 : principes fondamentaux de la RFC 8986

La RFC 8986 structure le concept de programmation réseau : l'idée qu'un itinéraire et ses fonctions associées s'expriment sous la forme d'une suite ordonnée d'instructions encodées dans une adresse IPv6 de 128 bits.

Au lieu de tenir à jour des tables de tunnels complexes, la passerelle d'entrée encode l'intégralité du trajet sous la forme d'une séquence d'identifiants de segment (Segment Identifiers - SID). À mesure que le paquet progresse sur la dorsale, chaque nœud compatible SRv6 lit le SID actif, applique l'instruction correspondante et passe au segment suivant.

Anatomie d'un SID 128 bits : décomposition Locator, Function et Arguments

Un SID SRv6 adopte strictement la syntaxe d'une adresse IPv6 standard de 128 bits, divisée en trois champs fonctionnels :

$$ ext{SRv6 SID (128 bits)} = ext{Locator} ,|, ext{Function} ,|, ext{Arguments}$$

  • Locator ($L$ bits) : Préfixe IPv6 attribué à un équipement déterminé. Les routeurs intermédiaires acheminent le paquet vers ce nœud via le chemin le plus court IGP (IS-IS ou OSPFv3) sans devoir interpréter SRv6.
  • Function ($F$ bits) : Code d'opération (opcode) désignant l'action réseau spécifique à exécuter (ex. commuter vers un lien X, décapsuler dans une table VRF Y ou soumettre à un pare-feu).
  • Arguments ($A$ bits) : Paramètres optionnels de l'instruction, tels que des identifiants de flux ou des repères de qualité de service.

Par exemple, avec un préfixe de localisation en /64 et une fonction de 16 bits, 2001:db8:acad:1:: désigne la passerelle d'extrémité, tandis que 2001:db8:acad:1:0042:: lui ordonne d'exécuter la fonction 0x0042 (comme diriger la charge utile vers une table de routage VPN isolée).

L'en-tête Segment Routing (SRH) : analyse du paquet selon la RFC 8754

Afin d'acheminer une liste ordonnée de segments, la RFC 8754 définit l'en-tête d'extension Segment Routing Header (SRH, Routing Type 4) :

+-------------------------------------------------------------------+
| Next Header (8) | Hdr Ext Len (8) | Routing Type (4) | Segments Left (8) |
+-------------------------------------------------------------------+
| Last Entry (8)  | Flags (8)       | Tag (16)                             |
+-------------------------------------------------------------------+
| Segment List[0] (128 bits - SID de destination finale)            |
+-------------------------------------------------------------------+
| Segment List[1] (128 bits - SID d'instruction intermédiaire)      |
+-------------------------------------------------------------------+
| Segment List[2] (128 bits - SID de transit initial)               |
+-------------------------------------------------------------------+

Les champs de commande essentiels sont :

  • Segments Left (SL) : Pointeur désignant l'indice du segment actif suivant dans la liste.
  • Segment List : Tableau ordonné d'adresses IPv6 de 128 bits, inscrit dans l'ordre inverse d'exécution (l'élément Last Entry est traité en premier, l'élément d'indice 0 en dernier).

Lors de la transmission, l'adresse de destination IPv6 externe contient en permanence le SID actif. Dès réception, le nœud décrémente Segments Left, recopie Segment List[SL] dans le champ d'adresse de destination et réexpédie le paquet vers le locator suivant.

Paradigme du routage à la source : élimination des états intermédiaires de transit

SRv6 transfère l'ensemble de l'intelligence aux frontières du réseau. La passerelle d'entrée détermine la politique complète d'acheminement — selon la latence mesurée, la disponibilité des liens ou les accords de niveau de service — et insère la liste des SID appropriée dans le paquet.

Cette approche apporte des gains d'exploitation majeurs :

  • Cœur de réseau sans état : Les routeurs de transit ne maintiennent que les routes IPv6 standard pour les locators. Ils sont totalement exempts d'états de tunnels ou de tables de commutation d'étiquettes.
  • Politiques de transit sur mesure : La passerelle d'entrée peut astreindre le trafic à emprunter des opérateurs spécifiques ou des liaisons optiques dédiées par simple ajout de segments.
  • Interopérabilité transparente : Les routeurs ne prenant pas en charge SRv6 continuent d'acheminer les paquets selon l'adresse IPv6 de destination standard, facilitant un déploiement graduel sans rupture.

Re-routage rapide TI-LFA : basculement déterministe sous 50 ms sans RSVP-TE

Une défaillance de lien physique sur une dorsale perturbe immédiatement les communications interactives. La convergence classique en environnement IP nécessite plusieurs centaines de millisecondes pour détecter l'incident, propager les annonces et recalculer les tables.

La technologie TI-LFA (Topology-Independent Loop-Free Alternate) garantit une protection automatique et déterministe inférieure à 50 millisecondes sur n'importe quelle topologie :

  1. Calculs préalables des routes de secours : Les routeurs évaluent en amont les chemins alternatifs post-convergence à l'aide de l'algorithme de Dijkstra.
  2. Suppression des boucles transitoires : Contrairement au mécanisme LFA classique (RFC 5286) qui échoue en topologie complexe en raison de risques de rebouclage, TI-LFA cible précisément le nœud de libération post-convergence ($Q$-node).
  3. Guidage par segments : Lors d'une coupure, le routeur injecte des segments SRv6 pour dévier le flux autour du lien défaillant jusqu'au nœud $Q$, qui achemine ensuite le paquet sans incident.

Dès la détection matérielle de la coupure, la carte réseau commute les paquets sur la liste de segments de secours TI-LFA précalculée. Le basculement s'opère en moins de 50 ms, évitant les micro-boucles et limitant les pertes de paquets.

Mappage des services SRv6 : encapsulation des overlays L3VPN et Anycast

La RFC 9252 formalise la transmission des services VPN overlay par MP-BGP sur une infrastructure SRv6. Au lieu de distribuer des étiquettes MPLS de 32 bits, BGP propage directement des SID SRv6 associés aux instances réseau :

  • End.DT4 / End.DT6 : La passerelle distante décapsule l'en-tête externe IPv6 et transmet la charge utile IPv4 ou IPv6 à la table de routage virtuel (VRF) ciblée.
  • End.DX4 / End.DX6 : Décapsule et réachemine le flux directement vers une interface client point-à-point dédiée.
  • Anycast SID : Un même locator annoncé conjointement par plusieurs centres de données Anycast. Le trafic envoyé vers un Anycast SID atterrit automatiquement sur la passerelle opérationnelle la plus proche.

Cette architecture simplifie l'exploitation des réseaux multi-tenants, supprime la signalisation LDP et assure un partitionnement étanche des flux clients.

Surcharge MTU et Micro-SIDs (uSID) : surmonter le gonflement des en-têtes IPv6

Chaque SID de 128 bits présent dans l'en-tête SRH ajoute 16 octets de surcharge. Une règle nécessitant une chaîne de 4 segments induit une augmentation de 72 octets par paquet.

Pour préserver la bande passante et éliminer le risque de fragmentation MTU, deux démarches d'ingénierie sont couramment mises en œuvre :

  1. Adoption des Micro-SIDs (uSID) : Selon les spécifications de compression de l'IETF, le format uSID agrège plusieurs commandes courtes de 16 ou 32 bits au sein d'un conteneur IPv6 unique de 128 bits. Un seul en-tête peut ainsi réunir jusqu'à 6 instructions, diminuant de plus de 75 % la surcharge d'extension.
  2. Ajustement dynamique MSS (MSS Clamping) : Les passerelles ajustent la valeur de négociation MSS lors des poignées de main TCP SYN, empêchant les paquets des hôtes de dépasser la MTU du chemin.

Considérations de sécurité : limiter le domaine de confiance SRv6 aux passerelles d'entrée

Puisque les instructions d'acheminement sont codées dans l'adresse de destination, des paquets externes non autorisés portant des SID internes pourraient être exploités pour déclencher des fonctions réseau indues.

Les RFC 8754 et RFC 8986 circonscrivent explicitement le Domaine de confiance SRv6 (SRv6 Trusted Domain) : un périmètre réseau supervisé et sécurisé où les paquets SRv6 sont émis, validés et décodés.

Vérification de signature HMAC et prévention des altérations du SRH

La section 2.1 de la RFC 8754 autorise l'intégration d'un champ HMAC TLV facultatif dans le SRH. Au moyen de clés cryptographiques partagées, les passerelles de frontière signent numériquement les données de routage :

  • Le nœud d'entrée calcule un condensé HMAC couvrant la liste des SID et les champs critiques de l'en-tête IPv6.
  • Les routeurs de contrôle vérifient la conformité de la signature avant d'exécuter des instructions sensibles.
  • Tout paquet présentant des SID modifiés ou une signature invalide est éliminé instantanément au niveau matériel.

Filtrage aux frontières via BCP 38 pour empêcher l'injection externe de SID

Les équipements de périmètre et pare-feux doivent instaurer des filtres de contrôle stricts :

  1. Filtrage à l'entrée : Rejet systématique de tout paquet externe provenant d'Internet et contenant un en-tête SRH ou visant les préfixes locators internes.
  2. Nettoyage à la sortie : Retrait intégral des en-têtes SRH avant que les paquets ne quittent le domaine de confiance pour éviter la divulgation de la topologie interne.
  3. Protection anti-usurpation : Déploiement rigoureux des contrôles de source BCP 38 / RFC 2827 afin d'interdire l'usurpation des adresses IP des passerelles internes.

Backbone Anycast RiceGuard : ingénierie de maillage SRv6 déterministe

VPNRice déploie l'architecture maillée RiceGuard de niveau 3 pour interconnecter ses présences Anycast mondiales à travers les transitaires Tier-1. Dans des environnements distribués denses, les fluctuations de connectivité des opérateurs peuvent entraîner des instabilités de routage et des ruptures de session.

Le réseau RiceGuard intègre SRv6 pour consolider la haute disponibilité et restreindre la latence :

  • Basculement TI-LFA instantané : Les routeurs principaux basculent automatiquement les liens interrompus vers des trajets optiques de réserve en moins de 35 millisecondes.
  • Ingénierie de trafic sans état : RiceGuard insère dynamiquement des micro-SIDs dans le trafic Anycast afin de éviter les tronçons saturés sans imposer de suivi d'état au cœur du réseau.
  • Migration Anycast sans coupure : Les flux basculent de manière transparente entre les centres de données lors des phases de maintenance grâce à des SID de délestage programmés.
  • Télémétrie en temps réel : Une surveillance permanente contrôle les seuils MTU et la qualité des liens. Les utilisateurs peuvent vérifier la configuration de leur connexion via la page /what-is-my-ip.

Les utilisateurs recherchant des liaisons stables et protégées peuvent télécharger les applications officielles depuis /download. Les mécanismes de dispersion multipath par port d'entropie sont détaillés dans /news/gre-in-udp-rfc-8086-geneve-ecmp-hash-polarization-vpn, tandis que la résilience du routage Anycast lors des transitions BGP est analysée dans /news/bgp-graceful-restart-rfc-4724-llgr-anycast-resilience.

Mise en œuvre pratique : configuration des terminaisons SRv6 et de l'encapsulation sous Linux

Le noyau Linux supporte nativement la programmation réseau SRv6 et l'encapsulation de segments par le biais d'outils de la suite iproute2. Les administrateurs peuvent paramétrer les flux SRv6 avec les commandes standards.

Activation du routage IPv6 et du sous-système Segment Routing :

Activer le transfert IPv6 et le traitement seg6 sur la Passerelle A :

# Activation du routage IPv6 et du support seg6 sur les interfaces
sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv6.conf.all.seg6_enabled=1
sysctl -w net.ipv6.conf.eth0.seg6_enabled=1

Configuration de l'encapsulation SRv6 en entrée :

Acheminer le trafic destiné à un sous-réseau via une politique SRv6 en l'encapsulant dans un en-tête IPv6 porteur de la liste des segments :

# Encapsulation du trafic vers 10.100.0.0/16 selon un itinéraire SRv6
ip -6 route add 10.100.0.0/16 encap seg6 mode encap     segs 2001:db8:beef:2::,2001:db8:acad:1::     dev eth0

Dans cette configuration, les paquets émis sont enveloppés dans un en-tête IPv6 où le premier segment actif est 2001:db8:acad:1:: et la destination finale 2001:db8:beef:2::.

Configuration de la fonction End.DT4 sur la passerelle de sortie :

Sur la Passerelle B, assigner au locator l'instruction de décapsulation et de livraison des données IPv4 à une table VRF :

# Affectation de l'action End.DT4 au SID pour orientation vers la VRF
ip -6 route add 2001:db8:acad:1::/64 encap seg6local action End.DT4     vrftable 100     dev eth0

Contrôle de l'état des liaisons SRv6 par télémétrie :

Consulter les routes d'encapsulation actives :

ip -6 route show encap seg6

10.100.0.0/16  encap seg6 mode encap segs 2 [ 2001:db8:beef:2:: 2001:db8:acad:1:: ] dev eth0 metric 1024

Vérifier la structure des paquets en transit avec tcpdump pour observer l'en-tête Routing Type 4 :

tcpdump -ni eth0 'ip6[6] == 43' -vv

07:18:22.410928 IP6 2001:db8:feed:1:: > 2001:db8:acad:1::: HBH, routing (type 4, segleft 1, [2] 2001:db8:beef:2::, [1] 2001:db8:acad:1::)

La télémétrie atteste de la présence active de l'en-tête SRH et de l'incrémentation rigoureuse des segments, concrétisant un routage à la source déterministe sur le réseau de transport.