Latest revision as of 12:01, 10 February 2006

Déploiement du multicast

Table des matières

Etude pratique du déploiement du multicast IPv6

L'objectif des passerelles IPv6/IPv4 est de permettre à des utilisateurs répartis dans les réseaux IPv6 et IPv4 multicast de participer à une même session multicast. Il existe des passerelles statiques aussi appelées réflecteurs qui permettent à des groupes IPv4 et IPv6 prédéfinis de communiquer. Une passerelle dynamique a aussi été conçue et implémentée permettant une complète interaction entre les réseaux multicast IPv6 et IPv4.

Réflecteurs

Ce type de passerelle permet d'assurer la correspondance entre un groupe IPv4 et un groupe IPv6 multicast. Sur chaque passerelle, les adresses des groupes IPv4 et IPv6 sont configurées statiquement. Ces réflecteurs peuvent donc être utilisés pour des sessions périodiquement utilisées sur des adresses IPv4 et IPv6 qui ne changent pas. La passerelle déployée sur RENATER traduit d'IPv4 à IPv6 (et vice versa) des sessions d'enseignement à distance, ainsi que des conférences organisées sur les thèmes des réseaux.

Une passerelle s'abonne aux groupes IPv4 et IPv6 multicast qui sont rentrés en paramètre. Pour cela, elle envoie un message IGMP report sur l'interface vers le réseau multicast IPv4 et un message MLD report vers le réseau multicast IPv6. Il est bien évidemment possible d'utiliser une seule interface physique lorsque le multicast IPv4 et IPv6 sont configurés sur le même lien-local.

Une fois les messages IGMP et MLD report envoyés (cf. figure Réflecteur IPv6/IPv4 multicast), la passerelle reçoit les flux multicast correspondants et n'a plus qu'à faire la traduction des en-têtes.

Dans le paquet traduit, l'adresse source est l'adresse (IPv4 ou IPv6) de la passerelle et l'information de la source est perdue. Cependant, l'expérience acquise montre que beaucoup d'applications utilisent la couche applicative pour identifier les différents participants de la session. L'utilisation d'une passerelle devient donc transparente pour les différents utilisateurs.

Un problème peut survenir lors du déploiement de réflecteurs si deux passerelles sont configurées pour les mêmes groupes. Une boucle est alors créée dans le réseau ce qui sature les liens du réseau. Pour limiter la probabilité d'avoir ce genre de problème, il est possible de configurer une passerelle avec les ports UDP utilisés. La probabilité d'avoir deux passerelles pour les mêmes adresses et numéros de ports devient quasi nulle. Il ne faut pas non plus voir ce problème comme une faille de sécurité car une personne malveillante peut émettre une forte quantité de trafic dans les groupes considérés pour saturer les liaisons et les équipements, et n'a pas besoin de passerelle pour cela. Un contrôle du débit maximal utilisable sur chaque groupe est une bonne solution pour éviter des conséquences trop importantes de ces attaques par déni de service.

Passerelles dynamiques

L'intérêt d'une telle passerelle est de pouvoir traduire n'importe quelle session IPv4 en IPv6 et vice-versa sans configuration préalable. Un utilisateur peut déployer le multicast IPv6 et arrêter le multicast IPv4 car il pourra avoir accès à tous les services IPv4 multicast grâce à la passerelle.

Le principe de base de cette passerelle est d'utiliser l'adresse IPv4 multicast comme identifiant de groupe de l'adresse multicast IPv6. La passerelle dynamique est donnée figure Principe de la passerelle dynamique IPv6/IPv4 multicast.

• Un point de rendez-vous dans le réseau multicast IPv6 pour le préfixe qui lui est associé,
• Un client terminal dans le réseau multicast IPv4.

Quand un client multicast IPv6 veut recevoir du flux multicast IPv4, il envoie un message MLD report pour l'adresse IPv6 multicast dérivée du préfixe multicast associé à la passerelle et de l'adresse IPv4 multicast. Le DR du lien envoie alors un message PIM join pour cette adresse qui sera propagé jusqu'à la passerelle puisqu'elle est configurée comme RP pour le préfixe utilisé. La passerelle retrouvera l'adresse IPv4 dans le paquet et enverra un message IGMP report pour cette adresse IPv4. Le trafic IPv4 multicast atteindra ensuite la passerelle qui traduira les paquets comme cela est expliqué dans la partie précédente concernant les passerelles statiques.

Lorsqu'une source émet du trafic multicast IPv6 avec des adresses associées à la passerelle, le DR sur le lien-local encapsule ce trafic vers la passerelle puisqu'elle est configurée comme point de rendez-vous pour le préfixe utilisé. La passerelle va traduire ensuite les en-têtes de la même manière qu'une passerelle statique en utilisant l'adresse IPv4 embarquée dans l'adresse IPv6. Les paquets traduits sont envoyés sur l'interface multicast IPv4. Comme expliqué dans la section consacrée à PIM, les paquets pourront être transmis de maniére native entre la source et le RP afin d'éviter le coût lié à l'encapsulation dans les messages PIM register.

Pour rendre l'usage de ces passerelles encore plus facile, il est possible de traduire d'IPv4 à IPv6 les annonces SAP de toutes les sessions IPv4. Ainsi une session IPv4 annoncée par SAP sera visible par les clients multicast IPv6, avec des adresses automatiquement traduites pour permettre d'utiliser la passerelle. Il est ainsi possible pour un site de se passer entièrement du multicast IPv4, en gardant la certitude d'avoir accès à tous les services associés.

Déploiement du multicast

Table des matières

Etude pratique du déploiement du multicast IPv6