Mon blog

Les relations du protocole de routage OSPF avec le fait qu'il existe plusieurs familles de protocoles IP (IPv4 et IPv6) ont toujours été compliquées. En pratique, la totalité des déploiements actuels d'OSPF dans un environnement mixte (v4 et v6) se font avec deux installations séparées, une utilisant OSPF v2 (RFC 2328) pour IPv4 et une utilisant OSPF v3 (RFC 5340) pour IPv6. Cela complique la tâche de l'administrateur réseaux et notre RFC propose donc une autre approche, un mécanisme simple pour utiliser le protocole le plus récent, OSPF v3, pour toutes les familles.

Ce n'est pas la première tentative pour faire d'OSPF v3 (normalisé dans le RFC 5340) un protocole de routage multi-familles. Mais, jusqu'à présent, OSPF v3 n'était utilisé que pour IPv6. Ce RFC 5838 vise la simplicité en minimisant les changements au protocole. Il s'appuie sur un mécanisme existant d'OSPF v3, les instances (section 2.4 du RFC 5340). En gros, chaque instance est une incarnation du protocole OSPF, avec sa propre base, mais gérée par le même routeur (ce qui minimise le travail pour l'administrateur).

La section 1 précise que chaque famille d'adresse (IPv4, IPv6 mais aussi des choses plus exotiques comme multicast IPv6) sera mise en correspondance avec une instance OSPF v3. Cela permet d'atteindre l'objectif de simplicité (section 1.1) puisqu'on n'introduit pas de nouveau mécanisme, les instances existant déjà) mais cela empêche les différentes familles de partager l'information, chaque instance ayant sa propre base de données. Si un lien qui sert à IPv4 et IPv6 tombe, il faudra le détecter deux fois et faire les calculs SPF deux fois (routage dit des « navires dans la nuit » car les différentes instances ne se voient pas : elles partagent le logiciel et une partie de la configuration, mais pas les bases).

La section 2 détaille l'affectation des numéros d'instance (Instance ID, un octet dans l'en-tête OSPF). L'idée est d'affecter des plages de numéros d'instances à chaque famille. Ainsi (section 2.1), l'unicast IPv6 a les numéros de 0 à 31, l'unicast IPv4 de 64 à 95, etc (128 à 255 sont actuellement libres, un RFC ayant le statut de norme étant nécessaire si on veut les utiliser). La liste complète des plages figure dans un registre IANA (cf. section 5).

À noter que OSPF v3 tourne uniquement sur IPv6, même lorsque les routeurs échangent de l'information sur des préfixes IPv4. Il faut donc activer IPv6 sur tous les liens, même si IPv6 n'est pas routé (un routeur OSPF v3 utilise les adresses « locales au lien » pour communiquer avec ses pairs).

Comme les routeurs OSPFv3 qui utilisent notre nouveau RFC coexisteront dans les réseaux avec les « vieux » routeurs, il est préférable d'avoir un mécanisme de signalisation pour les distinguer. C'est l'objet de la section 2.2 qui définit les bits du champ Options de OSPF (annexe A.2 du RFC 5340). Le bit v6, qui était déjà défini, est désormais ignoré (puisque la famille d'adresses est indiquée via l'Instance ID et un nouveau bit reçoit une signification, le n° 15, le bit AF (pour Address Family) qui, s'il est mis à un, indique un routeur conforme à ce RFC 5838. Un routeur configuré pour notre RFC doit ignorer les paquets où ce bit n'est pas mis (section 2.4) sauf pour l'unicast IPv6 (afin de pouvoir continuer à utiliser OSPFv3 comme avant). Cette heureuse coexistence entre anciens en nouveaux est décrite plus précisément en section 3.

En revanche, il n'y a pas de changement dans la définition des LSA (Link State Advertisements, les paquets qui portent la description d'un lien), OSPFv3 les avait déjà prévu « multi-protocoles » en indiquant explicitement la longueur du préfixe et la famille d'adresses (section 2.3). De même, l'adresse du routeur à utiliser n'est pas celle du pair OSPF (qui est forcément une adresse IPv6) mais est mise dans le LSA (section 2.5 ainsi que la section 4.4.3.8 du RFC 5340) et peut donc être une adresse IPv4.