RFC 8950 : de l'IPv4 sans adresse IPv4 aux IXP

Faut-il encore une adresse IPv4 sur chaque lien d'interconnexion pour échanger du trafic IPv4 ? Pas forcément. Le standard RFC 8950 permet d'annoncer des routes IPv4 en BGP avec une adresse de prochain saut (next-hop) en IPv6. Dans un article publié le 19 octobre sur RIPE Labs, André Grüneberg, directeur technique du point d'échange berlinois BCIX, décrit comment ce mécanisme peut alléger la consommation d'adresses IPv4 sur les points d'échange Internet (IXP).

Ce que dit le RFC 8950

Publié par l'IETF en novembre 2020, le RFC 8950 remplace le RFC 5549. Il part d'une limite de BGP multiprotocole : pour les routes IPv4, le champ « next hop » ne pouvait contenir qu'une adresse IPv4. Impossible, donc, de relier des îlots IPv4 à travers un cœur de réseau uniquement IPv6 sans tunnel ni traduction.

Le standard lève cette contrainte. Un routeur peut placer une adresse IPv6 comme prochain saut d'une route IPv4, unicast ou VPN. Le récepteur reconnaît le format à la longueur du champ. Pour éviter les malentendus, les deux pairs doivent d'abord s'accorder via une capacité BGP dédiée, l'« Extended Next Hop Encoding » (code 5) : un routeur ne doit pas envoyer de route IPv4 avec un next-hop IPv6 à un voisin qui ne l'a pas annoncée.

Le RFC ne crée pas de nouveau problème de sécurité par rapport à BGP, mais il note un risque de détournement de trafic plus facile, le prochain saut pouvant être une cible IPv6 distante. Les contrôles de next-hop doivent en tenir compte.

Pourquoi cela intéresse les points d'échange

Sur un IXP, chaque membre reçoit habituellement deux adresses sur le réseau de peering : une IPv4 et une IPv6. Avec le RFC 8950, une seule session BGP en IPv6 peut transporter les deux familles de routes. Pour retrouver l'adresse matérielle du prochain saut, le routeur utilise alors le protocole Neighbor Discovery d'IPv6 plutôt qu'ARP.

La démarche conseillée par l'auteur est progressive : activer l'option « extended next-hop » sur les sessions IPv6 existantes, y basculer les routes IPv4, puis supprimer la session IPv4 et, à terme, l'adresse IPv4 du lien. Il invite aussi les membres à demander à leur IXP la prise en charge du RFC 8950 sur les serveurs de routes.

Côté outils, le générateur de configuration arouteserver le gère nativement. IXP Manager demande encore d'adapter ses modèles BIRD ; BCIX a publié les siens. Le groupe de travail RFC 8950 d'Euro-IX recense par ailleurs la compatibilité de plusieurs systèmes d'exploitation réseau courants.

Les limites à connaître

Le premier obstacle est un problème de poule et d'œuf : seuls les membres qui utilisent eux aussi le RFC 8950 reçoivent ces routes IPv4. Un nouvel entrant sans adresse IPv4 ne peut donc pas joindre les réseaux restés en IPv4 classique sans passer par un routeur « traducteur ».

BCIX utilise ce type de traducteur de niveau 3. L'auteur cite deux réseaux raccordés ainsi sans adresse IPv4 sur le LAN de peering : V4LESS, de Tobias Fiebig, et le service DNS faisant autorité du RIPE NCC. La méthode a ses défauts. Le numéro d'AS du traducteur s'ajoute aux chemins, ce qui revient à une fuite de routes que le serveur de routes doit corriger. Il faut aussi régler les préférences pour que le trafic ne passe pas inutilement par ce relais.

Enfin, l'outillage suit mal : formulaires de provisionnement qui exigent un champ IPv4, modèles de configuration sans le mot-clé « extended-next-hop », looking glasses mal adaptés aux sessions mixtes. Le RFC 8950 ne remplace pas la transition vers IPv6, dont nous faisions le point dans notre article sur l'IPv6 en France, mais il permet d'économiser des adresses IPv4 devenues rares.