Résumé

  • RFC 4012 préserve la portée IPv4 unicast des attributs import, export et default, tout en ajoutant des attributs mp-* sensibles aux familles.
  • Dans ces nouveaux attributs, l’absence de clause AFI signifie any pour IPv4/IPv6 unicast et multicast ; elle ne signifie pas « aucune famille ».

Une AFI absente n’est pas une portée vide

Face à un mp-import sans clause afi, on pourrait croire que la famille visée n’est pas précisée. RFC 4012 tranche autrement : l’absence de cette clause vaut any, une portée définie qui englobe IPv4 unicast, IPv4 multicast, IPv6 unicast et IPv6 multicast. Le champ manquant porte donc une règle ; il ne laisse pas à chaque lecteur ou parseur le soin d’improviser.

Ce défaut ne s’applique qu’aux nouveaux attributs mp-*. Les anciens import, export et default gardent leur sens IPv4 unicast. RFC 4012 évite ainsi deux ambiguïtés : les enregistrements hérités ne changent pas de signification sans avertissement, et une expression multiprotocole sans AFI n’est pas dépourvue de portée. Le premier contrôle consiste à comprendre ce que la grammaire a déjà décidé avant d’interpréter le reste de la ligne.

Le point de départ était l’unicast IPv4

RFC 2622, publié en 1999, définissait RPSL pour les politiques de routage unicast IPv4. Les attributs import, export et default avaient donc un sens établi dans ce cadre. En mars 2005, RFC 4012 a étendu le langage vers IPv6 et le multicast, tout en conservant la compatibilité avec les usages existants. RFC 2622 RFC 4012

La solution était explicite plutôt que magique. Les anciens attributs gardent leur portée unicast IPv4 ; les attributs mp-import, mp-export et mp-default expriment les cas multiprotocoles. Une clause afi peut désigner, par exemple, ipv6.unicast ou ipv6.multicast, mais aussi des portées plus larges. Quand la clause facultative est absente d’un attribut mp-*, RFC 4012 lui donne la portée any, couvrant les quatre familles définies. C’est une règle d’interprétation de la déclaration, pas la preuve qu’un équipement prend en charge ces familles. RFC 4012, sections 2.1 à 2.5

Ce détail prévient une confusion rétrospective : la présence d’IPv6 dans le vocabulaire ne signifie ni que les politiques IPv4 et IPv6 sont identiques, ni que tous les opérateurs les ont déployées de la même façon. La norme fournit des distinctions que le modèle antérieur ne rendait pas aussi lisibles.

Le dictionnaire compose aussi les portées : ipv4 et ipv6 couvrent chacune l’unicast et le multicast de leur version ; any.unicast et any.multicast réunissent un type de trafic sur les deux versions ; any rassemble les quatre combinaisons de base. La grammaire est concise parce que ces unions ont un nom, non parce que leur portée serait implicite.

Le même sigle AFI, mais pas la même couche

RFC 4012 ajoute aussi la classe route6, mais sa clé d’objet et l’autorisation de modification sont distinctes de la clause AFI facultative ; RFC 2725 traite cette question d’autorisation. Ce détour marque une frontière, pas un second sujet. RFC 4012, section 3 RFC 2725

BGP emploie lui aussi AFI/SAFI, mais RFC 4760 les associe à la joignabilité de la couche réseau et au prochain saut dans les messages UPDATE. Dans RPSL, la clause AFI facultative de RFC 4012 délimite une expression de politique. Le vocabulaire commun ne rend pas ces déclarations équivalentes ; sélection et annonce des routes relèvent du fonctionnement décrit par RFC 4271. RFC 4271 RFC 4760

Des unions nommées rendaient la grammaire combinable

On résume parfois en disant que RPSL a appris IPv6. Plus précisément, RFC 4012 a rendu la portée de famille d’une politique exprimable et a nommé les unions entre versions et types de trafic. Cela décrit le langage, pas une adoption uniforme des deux versions.

Cette précision compte parce que les décisions peuvent différer selon les familles : voisins, filtres, prochains sauts et annonces ne sont pas interchangeables. Un afi ipv6.unicast n’a pas la même portée qu’un afi any. Et même une portée correctement documentée n’enlève pas au réseau sa décision distincte d’accepter ou d’annoncer une route.

RFC 8212, publié en 2017, offre un repère chronologique : il exige des politiques EBGP explicites, mais traite du comportement BGP et ne change pas la règle de RFC 4012 lorsqu’une AFI est omise dans RPSL. RFC 8212

Les Notes 65 et 64 de Lu Heng servent ici de grille éditoriale : une couche commune doit rester liée aux besoins des systèmes qui l’adoptent et la font tourner. Il ne s’agit pas d’attribuer cette doctrine aux auteurs de RFC 4012. Elle permet plutôt de nommer la limite déjà visible dans l’architecture : RPSLng rend une politique plus lisible, tandis que le routeur demeure l’endroit où elle est chargée et exécutée. Note 65 Note 64

Les documents étudiés ne fournissent ni taux d’adoption de RPSLng, ni mesure de complétude des bases, ni résultat de déploiement IPv6 chez un opérateur. La conclusion étayée est plus étroite : RFC 4012 a rendu plus précise et déterministe la portée des expressions de politique RPSL.

Sources principales