Principe de fonctionnement

Le protocole MP‑BGP autorise déjà l’échange d’itinéraires IPv4 via des sessions IPv6 en conservant un next‑hop IPv4, et inversement. L’extension définie par RFC8950 inverse cette logique : pour un préfixe IPv4, le next‑hop indiqué est une adresse IPv6. Le plan de contrôle utilise donc uniquement IPv6, tandis que le plan de données transmet les paquets IPv4 sous forme native, sans encapsulation tunnel ni traduction de type 464XLAT. Le mécanisme repose sur la découverte NDP (Neighbour Discovery Protocol) de l’adresse MAC associée à l’adresse IPv6 du next‑hop, ce qui permet à la trame Ethernet de porter directement le paquet IPv4.

Implémentation et support matériel

Le texte indique que la plupart des plateformes de routage modernes implémentent déjà RFC8950, à condition d’utiliser une version récente du système d’exploitation. Parmi les implémentations citées figurent Juniper JunOS, Cisco IOS XR, Nokia SR OS, Mikrotik, Huawei, ainsi que les suites open‑source BIRD et FRR. Cette large adoption montre que le changement se situe uniquement au niveau du logiciel de contrôle (BGP) et ne requiert aucune modification du matériel de commutation.

Déploiement démonstratif

Un laboratoire Container‑Lab (version 0.76.1) a été construit pour valider le concept. Le fichier topology.yml décrit cinq nœuds : trois routeurs fournisseurs (R1‑R3) et deux clients (C1, C2). Tous les nœuds exécutent l’image frr-with-bgpd. Les adresses IPv6 de chaque conteneur sont du format 3fff:172:20:20::X, tandis que les adresses IPv4 de gestion sont dans le sous‑réseau 172.20.20.0/24. Voici un extrait du fichier de topologie :

name: rfc8950
topology:
  nodes:
    R1:
      kind: linux
      image: frr-with-bgpd
    R2:
      kind: linux
      image: frr-with-bgpd
    R3:
      kind: linux
      image: frr-with-bgpd
    C1:
      kind: linux
      image: frr-with-bgpd
    C2:
      kind: linux
      image: frr-with-bgpd
  links:
    - endpoints: ["C1:eth1", "R1:eth1"]
    - endpoints: ["R1:eth2", "R2:eth1"]
    - endpoints: ["R2:eth2", "R3:eth1"]
    - endpoints: ["R3:eth2", "C2:eth1"]

Dans ce scénario, C1 possède uniquement une adresse IPv6 sur son interface WAN et annonce le préfixe 10.0.0.0/24 via une session BGP IPv6 vers R1. R3, à l’inverse, ne possède que des adresses IPv4 vers C2 (préfixe 100.64.0.0/24) mais maintient une session IPv6 vers R2. Les routes IPv4 sont ainsi propagées à travers le réseau fournisseur uniquement grâce à des next‑hop IPv6. La vérification via show ip bgp 100.64.0.2 sur C1 montre une entrée BGP valide avec un next‑hop 2001:db8:0:1::1. Le traceroute confirme que le trafic passe par les trois routeurs intermédiaires avant d’atteindre C2, sans aucune encapsulation supplémentaire.

Limites et perspectives

Bien que le plan de données reste inchangé, l’adoption de RFC8950 impose que chaque nœud du cœur de réseau supporte MP‑BGP avec des next‑hop IPv6. Les environnements legacy qui ne disposent pas d’une pile IPv6 complète sur leurs interfaces de routage ne pourront pas profiter de ce mécanisme. De plus, la visibilité des routes IPv4 dans les tables de contrôle dépend de la configuration correcte des politiques de filtrage BGP, ce qui peut introduire des complexités opérationnelles. Néanmoins, la démonstration montre que, dès lors que le logiciel de routage le supporte, il est possible de déployer un réseau « IPv6‑only » tout en conservant la connectivité IPv4 pour les clients finaux, éliminant ainsi la surcharge de configuration d’interfaces IPv4 et de sessions BGP dual‑stack.