Résumé

  • Publié le 7 septembre 2026, draft-ietf-spring-sid-as-source-address-00 a le statut de document du groupe SPRING. Cette adoption ouvre un travail collectif ; elle ne vaut ni RFC, ni approbation définitive, ni validation d’un équipement.
  • Le mécanisme remplace, dans l’en-tête IPv6 externe, l’adresse de bouclage du PE d’entrée par le SID du service attendu à l’autre extrémité. Le pare-feu peut alors retrouver une relation symétrique entre l’aller et le retour.
  • Cette symétrie décrit le service et l’état de session. Elle ne désigne pas nécessairement un routeur, un client ou un droit d’émettre ; le draft signale lui-même les risques d’usurpation interne, de perte de traçabilité et de saturation des états.

Dans une encapsulation SRv6 courante, le PE d’entrée place sa propre adresse de bouclage dans le champ source externe. Le service VPN distant apparaît comme SID de destination : directement dans l’adresse IPv6 en mode best effort, ou comme destination finale au bout du Segment Routing Header. Un pare-feu qui comprend SRv6 peut lire ce dernier élément et créer une entrée de session.

Le retour ne présente pourtant pas l’image inversée. Le second PE utilise sa boucle locale comme source, tandis que le SID de service du premier devient la destination finale. Un équipement qui associe l’aller et le retour par un triplet ou un quintuplet compare donc des valeurs différentes. Il peut rejeter une réponse parfaitement routable, ou un message ICMP légitime, parce que son état ne reconnaît pas la conversation.

Le draft du 7 septembre change la sémantique plutôt que le pare-feu. Après avoir déterminé le L3 VPN, le PE choisit le SID de service que son homologue attend pour ce flux et l’inscrit comme source IPv6 externe. L’autre PE fait l’opération symétrique. Lorsque le SID figure en source, il est traité comme une adresse IPv6 ordinaire ; il n’exécute pas son comportement d’extrémité. L’astuce donne ainsi au pare-feu la paire qu’il sait inverser.

Mais elle remplace un repère de machine par un repère de service. La réussite de la comparaison prouve qu’un paquet satisfait la relation conservée dans la table au moment où il est examiné. Elle ne prouve pas quel châssis l’a créé, quel accès client l’a déclenché, si ce châssis était autorisé à employer le SID ou si la valeur n’a pas été imitée.

Les trois granularités proposées rendent l’arbitrage concret. Un SID par VRF ne demande aucune recherche supplémentaire, mais plusieurs CE deviennent une même source visible. Un SID par circuit d’accès sépare davantage sans nouvelle consultation. Un SID par préfixe offre la distinction la plus fine, au prix d’une recherche sur l’adresse source du paquet client dans la VRF. La préférence du draft — préfixe, puis AC, puis VPN/VRF — améliore l’attribution disponible ; elle n’annule ni le coût de calcul ni le risque de repli silencieux vers une identité plus large.

Le texte de sécurité est particulièrement utile parce qu’il contredit toute lecture triomphale. Les préfixes de locator étant routables dans le domaine, un nœud interne peut tenter d’émettre sous un SID qui lui est étranger. La programmabilité et le renouvellement des SID peuvent aussi accélérer la création et l’expiration des sessions, consommer la mémoire du pare-feu et conduire au débordement. Le draft exige donc de limiter strictement les flux autorisés à utiliser un SID source. L’anti-usurpation, l’autorité d’origine, la durée de vie et le budget d’état restent à construire.

Le cas ICMP apporte une preuve différente. Un ping SRv6 peut prendre un End SID comme source afin de tester le chemin retour. Un nœud de transit peut émettre une erreur depuis le SID dont le traitement a échoué, ce qui aide la tête de réseau à localiser l’étape concernée. Pour une erreur issue d’un VPN, le PE d’entrée doit encore traiter l’en-tête supérieur du paquet inclus afin de remettre l’ICMP interne au CE. Localiser un segment fautif n’authentifie pas le rapporteur et ne démontre pas la cause initiale.

La compression peut rompre le contrat de lecture. Avec RFC 9800, le dernier élément du routage peut ne pas être l’adresse reçue par la destination finale ; une liste compressée peut même résider dans l’adresse de destination sans SRH. Le nouveau draft recommande de conserver la destination ultime sans compression dans le dernier élément du SRH. Sans ce point stable, deux PE peuvent choisir les bons SID sources et le pare-feu reconstruire malgré tout deux destinations différentes.

Le paragraphe d’implémentation doit rester à sa juste place. Il déclare que les routeurs New H3C CR16000 et CR19000, à partir de la version 7.1.119, couvrent toutes les sections avec une maturité dite « production ». L’entrée vise encore le Draft-13 antérieur et ne rapporte aucune expérience particulière. Conformément à RFC 7942, le document précise que ces informations fournies par un contributeur n’ont pas été vérifiées par l’IETF et ne constituent pas une approbation. C’est un signal de code existant, pas un essai indépendant d’interopérabilité ou de performance.

La méthode de Heng Lu oblige à conserver ces niveaux séparés. L’adoption par un groupe est un fait de coordination ; la règle du PE est un état configuré ; le paquet et l’entrée du pare-feu sont des observations ; la livraison et l’attribution sont des résultats. Aucun niveau ne peut rédiger le suivant à sa place.

L’événement mérite donc une lecture précise. SPRING prend en charge une solution au rejet indu de trafic SRv6, mais cette solution transforme aussi l’adresse source en étiquette de service. Le dossier probant doit relier la génération du SID, les PE autorisés, la granularité effectivement choisie, la version du parseur, l’entrée de session, le paquet et le résultat client. La phrase juste est « le retour correspond à l’état ». « Nous connaissons la source » est une autre affirmation.

Sources

  1. IETF Datatracker — SID as source address in SRv6
  2. Draft de groupe 00
  3. Datatracker — draft antérieur
  4. Révision 13 du draft antérieur
  5. SRv6 Security Considerations, révision 16
  6. RFC 8402 — Architecture Segment Routing
  7. RFC 8754 — En-tête SRH IPv6
  8. RFC 8986 — Programmation réseau SRv6
  9. RFC 9252 — Services overlay BGP sur SRv6
  10. RFC 9259 — OAM dans SRv6
  11. RFC 9800 — Listes de segments SRv6 compressées
  12. RFC 7942 — Sections sur l’état des implémentations
  13. Heng Lu — Running-Code Primacy
  14. Heng Lu — Minimum Initial Specification
  15. Heng Lu — Reality Layers