J’ai encore vu passer récemment la question sur un forum: “Y’a-t-il un équivalent de MSDP pour IPv6 ?”. Ayant pas mal travaillé sur le sujet (et tout ce qui touche au multicast IPv6 d’une manière générale) je vais donc essayer de faire une réponse détaillée sur ce blog pour la communauté francophone.
MSDP ne supporte pas IPv6 (ou l’inverse) et il n’est a priori pas question que cela change. Le RFC3618 qui décrit MSDP est toujours “experimental” et il ne semble pas prévu d’en changer le statut. Il est donc difficile d’imaginer dans ces conditions une adoption par la communauté IPv6. Je rappelle brièvement que cette problématique ne concerne que le multicast en mode ASM (Any-Source Multicast), dans lequel un récepteur s’abonne à un groupe et désire recevoir le trafic de toutes les sources qui envoient des données à ce groupe. Dans le mode SSM (Source-Specific Multicast), la question de l’inter-domaine ne se pose pas puisque le récepteur s’abonne à un groupe en spécifiant la source (ou les sources) d’intérêt: aucun protocole de type MSDP n’est donc nécessaire pour découvrir les sources et le modèle est grandement simplifié.
Embedded-RP
La question qui se pose est donc “comment faire de l’interdomaine multicast ASM en IPv6?”. La réponse est embedded-RP (RFC3956), disponible sur les routeurs CISCO depuis déjà quelques années. Le principe d’embedded-RP (ou RP embarqué) consiste à profiter de la grande taille d’une adresse IPv6 multicast pour y insérer l’adresse du point de rendez-vous (RP). Comme il n’est pas possible d’insérer l’adresse unicast du RP (128 bits) dans une adresse multicast IPv6 (128 bits également), cette méthode suppose que l’adresse du RP soit d’un format particulier: ce format est bien décrit dans le RFC aussi je ne vais pas le décrire dans le détail ici. Sur les 64 derniers bits de l’adresse du RP, tous doivent être positionnés à 0 à l’exception des 4 derniers qui sont nommés Router Interface Identifier ou RIID.
La lecture d’une adresse multicast IPv6 de type embedded-RP permet automatiquement de déterminer le point de rendez-vous associé. Ce point de rendez-vous peut être n’importe où et la notion de domaine multicast n’existe plus (une source pouvant s’enregistrer sur le RP d’un réseau distant). Dans ces conditions un mécanisme comme MSDP n’est plus utile puisque toutes les sources et tous les récepteurs d’un groupe “utilisent” le même RP. Il faut donc voir embedded-RP comme un mécanisme permettant le group-to-RP mapping (c’est à dire une solution permettant de déterminer le RP correspondant à une adresse de groupe). Tous les routeurs doivent donc supporter embedded-RP pour que la solution fonctionne: le DR (Designated Router), le RP (point de rendez-vous) et tous les autres routeurs du réseau multicast IPv6. Les adresses multicast de type embedded-RP sont dans le préfixe par FF7x::/12. Le 7 correspond aux adresses multicast de type embedded-RP, le x correspond à la portée de l’adresse (E=global, 5=site…)
Si la solution technique existe, elle change le modèle connu en IPv4 dans lequel une source s’enregistre sur le RP de son domaine. Le modèle opérationnel change donc considérablement et il convient de le comprendre avant de le déployer, car les procédures de troubleshooting ne sont plus les mêmes: les PIM-registers traversant les domaines.
Comment déployer embedded-RP ?
Le mécanisme est automatiquement activé lors de l’activation du multicast IPv6:
ipv6 multicast-routing
Il est cependant possible de désactiver embedded-RP:
no ipv6 pim rp embedded
Pour configurer un point de rendez-vous de type embedded-RP il suffit d’utiliser les commandes habituelles de configuration de RP. La seule différence est que l’adresse du RP et les adresses de groupe configurées correspondent au mapping “embedded-RP” décrit dans le RFC3956. La configuration ne doit être faite que sur le RP:
ipv6 pim rp-address 2001:db8:cafe:f00d::1 EMBEDDED-RP-GROUP ipv6 access-list EMBEDDED-RP-GROUP permit ipv6 any FF7E:140:2001:db8:cafe:f00d::/96
Et maintenant ? Comment utiliser le service ?
Embedded-RP impose d’utiliser des adresses IPv6 multicast qui “marchent”, c’est-à-dire dérivées d’un RP existant configuré. Ces adresses ne peuvent pas se deviner aussi à mon avis le mécanisme global ne sera complet qu’avec un mécanisme permettant d’allouer des adresses multicast IPv6. J’avais il y a déjà quelque temps proposé des mécanismes:
- Basés sur DHCPv6: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01
- Basés sur SLAAC: draft-jdurand-ipv6-multicast-ra-00.txt
- Imposant que tous les DR soient des RP: draft-jdurand-all-drs-are-rps-00
Ces propositions n’ont pas avancé à l’époque, pousser SSM en avant étant selon la communauté la meilleure façon d’avancer de façon pragmatique.
Authors
1 commentaires
très intéressant