Résumé

  • RFC 8950 permet d’annoncer des NLRI IPv4 et VPN-IPv4 avec un next hop IPv6. Le code de capability 5 ne promet que la compréhension d’un triplet précis — AFI de la NLRI, SAFI de la NLRI, AFI du next hop — et ne prouve ni l’activation de la famille ni l’accessibilité du next hop.
  • Le récepteur déduit le type du next hop de la longueur encodée. Un route reflector doit conserver l’encodage reçu et ne peut transmettre la NLRI à un client qui n’a pas annoncé sa capacité à le traiter.
  • La preuve utile relie les deux OPEN, l’MP_REACH_NLRI exact, la politique d’import, la résolution IPv6, la route sélectionnée, le FIB, l’adjacence ou le tunnel et les paquets IPv4. Une session verte n’est que le début.

À 1 h 40, un site d’agrégation bascule son cœur de transport vers un underlay IPv6 unique. Les services clients et leurs préfixes restent en IPv4. L’objectif est de ne plus entretenir deux plans d’adressage et deux états IGP sur chaque lien du cœur.

Deux route reflectors et la majorité des clients supportent le mécanisme. Un client récemment remplacé annonce dans OPEN la famille IPv4 unicast et Extended Next Hop Encoding. Un ancien client n’annonce que la première. Les deux sessions atteignent Established.

Le nouveau client reçoit les routes IPv4 et en choisit une. Les paquets échouent néanmoins : le resolver cherche l’adresse IPv6 du next hop dans une VRF de gestion et aboutit à une interface qui n’appartient pas au chemin de service. L’ancien client ne reçoit pas la route. Le reflector n’a pas le droit de transformer silencieusement son next hop IPv6 en adresse IPv4.

Le scénario est fictif, ses frontières ne le sont pas. RFC 8950 ne fusionne pas IPv4 et IPv6. Il place dans une même annonce deux affirmations typées : la destination est IPv4 ; le point vers lequel il faut résoudre le chemin est IPv6.

La destination et le next hop ne répondent pas à la même question

Une NLRI décrit une destination joignable. Le next hop indique vers quelle adresse le système récepteur doit résoudre et transférer pour exploiter cette joignabilité. Les deux appartiennent souvent à la même famille, au point que les outils ont fini par présenter cette habitude comme une nécessité.

MP-BGP expose leur séparation. MP_REACH_NLRI porte l’AFI, la SAFI, la longueur et les octets du next hop, puis la NLRI. RFC 4760 fournit ce conteneur. Les anciennes définitions IPv4 et VPN-IPv4 ne prévoyaient qu’un next hop de forme IPv4, ce qui empêchait d’exprimer proprement un service IPv4 au-dessus d’un cœur IPv6.

RFC 8950 ajoute une combinaison. L’AFI 1 continue de désigner une NLRI IPv4. Pour les SAFI définies, l’AFI du next hop peut être 2, donc IPv6. L’adresse du client n’est pas traduite et l’obligation de service IPv4 ne disparaît pas ; seule l’ancre de transport change de famille.

Cette construction reste volontaire. Un opérateur peut l’activer dans un seul domaine, sur quelques pairs ou pour une famille de service précise. Un équipement qui ne l’adopte pas n’acquiert pas un statut fautif ; il reste dans un autre ensemble de compatibilité. Le standard fixe une syntaxe minimale, pas un calendrier central de migration.

Il faut appliquer la même précision au terme « cœur IPv6-only ». Un underlay unique peut réduire l’état dupliqué. Il ne supprime ni les clients IPv4, ni les contrats, ni la valeur des ressources d’adressage, ni les compétences de dépannage. Le nom d’une couche ne décrit pas toute l’économie du service.

Le code 5 n’est pas un certificat général

Extended Next Hop Encoding porte le code 5. Sa valeur contient des triplets de six octets : deux pour l’AFI de la NLRI, deux pour sa SAFI et deux pour l’AFI du next hop. RFC 8950 autorise l’AFI 1, les SAFI 1, 2, 4, 128 ou 129, et l’AFI de next hop 2.

La granularité est essentielle. Un support prouvé pour IPv4 unicast ne vaut pas preuve pour labeled unicast, multicast ou VPN-IPv4. Les versions, cartes ou processus d’un même produit peuvent couvrir des sous-ensembles différents. Un booléen extended-nexthop dans un inventaire efface précisément ce qui a été négocié.

Le code 5 n’autorise pas non plus l’AFI/SAFI. La capability Multiprotocol de RFC 4760 décide séparément quelles familles les pairs peuvent échanger. Extended Next Hop Encoding ne fait qu’indiquer, pour une famille déjà admise, que le récepteur comprend un next hop d’une autre famille.

La preuve OPEN comporte donc deux contrôles : la famille MP-BGP visée est-elle annoncée des deux côtés ? Le récepteur annonce-t-il le triplet exact ? Une session peut rester Established sans l’un ou l’autre. Le sender ne doit employer l’encodage IPv6 pour une NLRI IPv4 qu’après avoir établi le second fait.

Cette petite convention illustre le Minimum Initial Specification de Heng Lu. Le protocole commun définit un code et une règle vérifiable ; il ne crée pas d’autorité de déploiement. Chaque extrémité décide localement ce qu’elle accepte, et l’effet d’une adoption partielle est une compatibilité limitée, pas une sanction institutionnelle.

La longueur fait partie du type

Pour l’AFI 1 avec les SAFI 1, 2 ou 4, un next hop IPv6 occupe 16 ou 32 octets. Seize octets transportent une adresse IPv6 ; trente-deux peuvent joindre une adresse globale et une link-local selon RFC 2545.

Pour les SAFI VPN-IPv4 128 ou 129, la forme IPv6 occupe 24 ou 48 octets. Elle utilise une adresse VPN-IPv6 précédée d’un Route Distinguisher de huit octets mis à zéro. RFC 8950 a corrigé l’encodage VPN de RFC 5549 pour l’aligner sur les implémentations déjà interopérables et traiter un erratum.

Le receiver doit déduire le protocole du next hop de cette longueur, à l’intérieur de ce que l’AFI/SAFI autorise. Il ne s’agit pas d’un détail d’affichage. Un collecteur qui convertit tout en chaîne non typée empêche ensuite de démontrer si l’information a été interprétée correctement.

Les adresses globales et link-local n’ont pas la même portée. Une adresse globale se résout dans une table. Une link-local ne devient un objet unique qu’avec une interface et un lien. Deux fe80::1 ne sont pas le même next hop. Toute preuve qui perd peer, interface et VRF peut rapprocher des objets étrangers.

La contrainte est forte sur une session eBGP unnumbered. Le transport BGP et la capability peuvent être corrects, tandis que le FIB manque de l’adjacence liée à l’interface. Un redémarrage ou un remplacement conserve parfois le texte de l’adresse tout en changeant le contexte qui lui donnait effet.

Un reflector ne traduit pas ce qu’il reflète

Lorsqu’un route reflector transmet le next hop sans le modifier, RFC 8950 lui interdit d’en changer l’encodage. Si un client ne sait pas le traiter, la NLRI ne peut pas lui être distribuée.

Remplacer l’adresse IPv6 par une IPv4 ne serait pas une opération de présentation. Cela créerait un nouveau point de résolution et transférerait la responsabilité du chemin vers une autre adresse, une autre politique et parfois un autre domaine de panne.

Une conséquence de topologie apparaît : si un client peut produire un encodage que d’autres doivent recevoir via un reflector commun, l’ensemble pertinent des clients doit être compatible. L’upgrade d’un edge peut révéler la limite d’un autre sans que le reflector soit défectueux.

L’absence est subtile. Le client ancien reste Established et continue de recevoir d’autres routes IPv4. Le reflector garde la route concernée. Une alarme de comptage signale un écart, mais ne dit pas que la déclaration de capability du client interdisait la distribution.

Il faut relier, dans le même epoch, l’UPDATE d’origine, la route acceptée par le reflector, l’OPEN du client cible et son Adj-RIB-Out. L’événement correct est « encodage non supporté par ce client », non « préfixe disparu ».

Une politique next-hop-self, un route server ou une confédération modifient la frontière et doivent être testés à part. Changer un next hop peut être légitime, mais devient alors une nouvelle décision de routage, et non une traduction invisible.

La récursion relie la syntaxe au réseau

Après acceptation de l’UPDATE, le receiver doit résoudre le next hop IPv6. Il choisit une table ou une VRF, trouve la route underlay, poursuit la récursion, attache une adjacence ou un tunnel, puis fournit le résultat au FIB.

Chaque transition peut casser seule : adresse absente de l’IGP, présence dans la table globale mais recherche dans une VRF, chaîne récursive incomplète, Neighbor Discovery défaillant, label ou SID absent, MTU insuffisante après encapsulation, line card en retard sur le control plane.

La chaîne de preuve est donc :

  1. famille MP-BGP annoncée ;
  2. triplet extended-next-hop exact ;
  3. MP_REACH_NLRI attendu sur le fil ;
  4. type interprété correctement ;
  5. route acceptée par la policy ;
  6. route sélectionnée ;
  7. next hop résolu dans le bon contexte ;
  8. destination IPv4 programmée dans le FIB ;
  9. paquets IPv4 transmis et retour vérifié.

Aucun niveau ne certifie le suivant. « BGP voit la route » est une phrase trop grossière. Le monitoring peut agréger les étapes, mais doit garder la provenance de chaque transition.

Le rollback suit la même discipline. Revenir à un next hop IPv4 peut exiger le retour de l’underlay IPv4, d’une policy next-hop-self, d’anciennes capabilities et d’un ordre précis d’annonces. Désactiver le code 5 sans restaurer le chemin précédent n’est pas un retour arrière.

La sécurité doit suivre le next hop vers IPv6

RFC 8950 n’authentifie pas une route. Une session TCP protégée peut transporter une annonce non autorisée. RPKI origin validation évalue l’origin AS d’un préfixe IPv4 ; elle ne prouve ni la légitimité ni l’accessibilité du next hop IPv6.

Les anciens outils peuvent supposer qu’une route IPv4 a nécessairement un next hop IPv4. Un inventaire ou une règle qui n’observe que ces adresses manque alors la nouvelle surface. RFC 8950 rappelle qu’un next hop IPv6 peut faciliter une diversion à travers une infrastructure IPv6 intermédiaire, avec risque de hijacking ou de denial of service. Il demande aussi de traiter correctement le cas inhabituel d’une adresse IPv4-mapped IPv6.

La réponse n’est pas le rejet systématique. Il faut expliciter quels peers peuvent annoncer un next hop IPv6 pour quelle famille, quelles portées sont admises, quelles tables et quels tunnels peuvent le résoudre, et quels services IPv4 peuvent en dépendre.

Transport authentication, GTSM, policy de préfixes, RPKI, autorisation du next hop, sécurité de l’underlay et validation par paquets restent des contrôles distincts. Leur corrélation est utile ; leur fusion produit une fausse certitude.

Le canary traverse les deux familles

Avant activation, choisir un préfixe IPv4 borné et un next hop IPv6 prévu. Conserver route, FIB, chemin de paquets, peer, table de résolution et triplets attendus sur chaque speaker.

Après ouverture d’un nouvel epoch BGP, capturer les deux OPEN. Vérifier séparément Multiprotocol et code 5. Inspecter ensuite l’UPDATE : AFI 1, bonne SAFI, longueur 16/32 ou 24/48, octets IPv6 exacts et NLRI inchangée.

Avec un reflector, démontrer la conservation du next hop et la capability de chaque client cible. Sur chaque receiver, conserver états pre-policy et post-policy, route sélectionnée, lookup récursif, table de sortie, adjacence ou tunnel et entrée FIB.

Enfin, envoyer des paquets IPv4 représentatifs et enregistrer source, destination, sens, retour, taille et epoch. Un ping ne couvre pas les effets d’encapsulation ou de MTU. Retirer ensuite le canary et vérifier le nettoyage dans Adj-RIB-Out, RIB, récursion et FIB.

Une ancienne configuration disponible dans Git ne rend pas le rollback réel. Le précédent chemin doit encore transporter des paquets dans le réseau actuel.

RFC 8950 fournit un langage commun déterministe. Les implémentations le rendent disponible, les opérateurs choisissent, et le réseau en exécution tranche. Le préfixe ne devient pas IPv6 parce qu’il traverse un cœur IPv6. La capability ne devient pas une autorité de forwarding parce que deux OPEN montrent le même numéro. Seul l’accord entre type, policy, récursion, matériel et paquets donne à la route sa portée réelle.