Jérôme Durand 5TC Stage du 2/7 au 31/12 2001 Stage Technique Renater - Aristote Diffusion en multicast IPv6 du séminaire Aristote du 20 décembre 2001 Année 2001-2002 INSA Lyon Département Télécommunications, services et usages 1
Remerciements Je voudrais remercier tout particulièrement Jacques Prévost et Bernard Tuy, mes deux tuteurs sur ce projet. Jacques Prévost m'a toujours donné les moyens nécessaires pour réaliser ce projet et ça a été un facteur très important quant à la bonne marche de celui-ci. Je remercie Bernard Tuy (Président du G6 et Unité Réseau du CNRS) pour son soutien, ses conseils et son expérience qui m'ont permis d'avancer beaucoup plus facilement sur le projet et de déployer plus rapidement le m6bone. Je le remercie d'autant plus pour m'avoir supporté six mois dans son bureau. Je remercie également Dany Vandromme, directeur du GIP pour m'avoir permis d'intégrer les locaux du GIP Renater et accepté de financer mes déplacements. Merci aussi à toutes les personnes qui ont collaboré pour le déploiement du M6Bone: Konstantin Kabassanov du LIP6, Luc Beurton de l'université de Bretagne Sud, Marcin Michalak de l'université Libre de Bruxelles, John Andrews de The University College of London et j'en oublie certainement Je remercie aussi les membres de l'équipe de CS du NOC Renater avec qui j'ai eu à travailler et en particulier Mathias Le Faucheur, Yann Le-Saout et Jean-Luc Helion. Je tiens enfin à saler l'esprit de camaraderie qui a régné pendant cette période de travail dans les locaux de Renater. 2
Sommaire 1 CONTEXTE GENERAL DU STAGE...4 1.1 L'ASSOCIATION ARISTOTE...4 1.2 LE STAGE : UN PARTENARIAT ARISTOTE - RENATER...4 1.3 LE RESEAU RENATER...5 1.4 LE GIP RENATER...6 2 LE PROJET IPV6 MULTICAST ET SON ENVIRONNEMENT...8 2.1 IPV6 ET SON DEPLOIEMENT DANS RENATER...8 2.1.1 Le protocole IPv6...8 2.1.2 Le pilote IPv6 de Renater...11 2.2 LA TECHNOLOGIE MULTICAST IP V6...13 2.2.1 Généralités...13 2.2.2 Les protocoles...13 2.2.3 Le déploiement et l'usage du multicast dans Renater...17 2.3 LE PROJET IP V6 MULTICAST...17 2.3.1 Définition du projet...17 2.3.2 Les enjeux du projet...17 3 LA REALISATION DU PROJET...19 3.1 INTEGRATION DU PROTOCOLE IP V6...19 3.1.1 Bibliographie de RFC sur IPv6...19 3.1.2 Evaluation d'un équipement IPv6...19 3.2 LA DIFFUSION DU SEMINAIRE ARISTOTE EN MULTICAST IP V6...20 3.2.1 Les équipements pour une visioconférence multicast IPv6...20 3.2.2 Etat de l'art du routage multicast IPv6...20 3.2.3 Une première topologie pour assurer la diffusion du séminaire...21 3.2.4 Déploiement d'une solution pérenne...26 3.3 TRANSFERT DE TECHNOLOGIES...28 3.3.1 Intégration des sites dans le réseau multicast IPv6...28 3.3.2 Conférences et cours...29 4 CONCLUSION...30 5 ANNEXES...31 5.1 BIBLIOGRAPHIE...31 5.1.1 Livres...31 5.1.2 Principaux sites web...31 5.2 LE PROTOCOLE MLDV2 ET LE PROTOCOLE PIM SSM...32 5.3 INSTALLATION DES OUTILS DU M6BONE...32 5.4 CARACTERISTIQUES DU ROUTEUR CENTRAL DU M6BONE...34 5.5 FORMULAIRE DE REQUETE DE CONNEXION AU M6BONE...35 5.6 CONFIGURATION D'UN ROUTEUR FREEBSD...36 5.6.1 Configuration des interfaces...36 5.6.2 Configuration des tunnels...37 5.6.3 Configuration des options de routage...38 5.6.4 Configurations multicast...41 5.6.5 Configurations diverses utiles sous FreeBSD...42 3
1 Contexte général du stage 1.1 L'association Aristote Aristote est une Association à but non lucratif régie par la loi de 1901. Ses objectifs se situent dans le domaine des techniques, moyens, outils et services de communication informatique : Mettre en commun les efforts de prospective d'étude et d'information faits par ses membres. Promouvoir l'élaboration et la mise en service de nouveaux produits, systèmes et services d'intérêt général au bénéfice des organismes membres. Organiser ou encourager des actions d'information ou de formation : Séminaires d'intérêt général, séminaires de formation technique, journées d'étude thématiques. Les activités d'aristote sont : des actions techniques, souvent organisées à l'intérieur de groupes de travail thématiques; et des actions de transmission du savoir. Les groupes de travail : rassemblant des experts des organismes membres de l'association et des experts invités, ils œuvrent dans les domaines tels que la sécurité, le graphique et les interfaces homme-machine, les applications scientifiques du web, le calcul scientifique distribué, la convergence téléphonie - données sur Internet, la pérennisation des informations numériques, les réseaux à haut débit, les contenus sémantiquement riches. Des actions techniques destinées à explorer ou évaluer des technologies avancées : certaines se situent dans le cadre de groupes de travail, d'autres sont plus ponctuelles. Aristote est donc un réel catalyseur pour répandre des technologies de pointe comme aujourd'hui IPv6 et les applications vidéos en multicast qui suscitent un intérêt de plus en plus grand. 1.2 Le stage : un partenariat Aristote - Renater C'est pour avancer dans ce domaine que l'association Aristote a proposé au GIP Renater, maître d'ouvrage du réseau Renater, de mettre en place un partenariat. L'objectif retenu était, si possible, la diffusion en audio et vidéo interactions, avec IPv6 multicast, du séminaire donné le 20 décembre 2001 par Aristote à l'ecole Polytechnique. L'objectif de mon stage est: la mise en œuvre d'un service pilote multicast IPv6 et en démonstration de ce service la retransmission audio et vidéo du 20 décembre, avec des applicatifs utilisant le multicast IPv6. Ce stage se déroule au GIP Renater. Les tuteurs en sont: Bernard Tuy, responsable des technologies IPv6 et IP multicast au sein du GIP Renater ainsi que président du G6, groupe chargé de tester, développer et promouvoir IPv6 en France; et, au titre d'aristote, Jacques Prévost (GIP Renater) chargé des applications avancées (visioconférences ) 4
1.3 Le réseau Renater Le Réseau National de Télécommunications pour la Technologie, l'enseignement et la Recherche a été déployé au début des années 90 pour fédérer les infrastructures de télécommunications pour la recherche et l'éducation. Le réseau Renater, une communauté d'utilisateurs Aujourd hui plus de 600 sites ayant une activité dans les domaines de la Recherche, la Technologie, l Enseignement et la Culture sont raccordés au réseau Renater. Ce réseau leur permet de communiquer entre eux, d accéder aux centres de recherche publics et privés, aux établissements d'enseignement du monde entier et à l Internet. Le réseau Renater est composé d une infrastructure nationale et de liaisons internationales à haut débit. Des points de présence de Renater sont également implantés dans les départements d Outre Mer. Renater comprend une épine dorsale nationale à haut débit - Renater 2 - qui fédère des réseaux de collecte régionaux développés avec le soutien des collectivités territoriales dans le cadre de l aménagement du territoire. Renater est interconnecté aux autres réseaux de recherche européens via le réseau paneuropéen GEANT et au continent nord-américain - et par son intermédiaire à la zone Asie - Pacifique - via deux liaisons dont une est exclusivement dédiée aux projets de recherche avec les réseaux des grands organismes scientifiques nord-américains (vbns, Internet 2, NASA, CANARIE) via le STAR TAP. Débit de l'épine dorsale de Renater Les débits des liaisons de l épine dorsale vont de 34 Mbits/s jusqu'à 2,5 Gbits/s. Ils peuvent même atteindre 80 Gbits/s en Ile de France. Services proposés par Renater Au niveau des points d'accès régionaux à son épine dorsale, Renater propose les principaux services suivants : Un service IP conventionnel permettant d accéder aux communautés de la recherche et de l enseignement, nationales et internationales ainsi qu à l Internet. 5
Un service de réseaux privés virtuels permanents (VPN) ou à la demande (VP) entre sites, avec une qualité de service garantie de bout en bout en utilisant ATM : il s'agit de services ATM natifs. Un service de diffusion IP (IP multicast). Un service pilote IPv6. Un accès à des contenus pédagogiques et culturels via une boucle à 2,5 Gbits/s reliant des sites à fort contenus culturels. Ces services peuvent être utilisés par tous les organismes et sites de la communauté Renater si ceux-ci sont reliés aux points de présence, par des réseaux de collecte régionaux qui les relaient. Un point d'échange de trafic nommé le SFINX (Service for French INternet exchange) a été déployé. Il permet à plus de 70 fournisseurs d'accès d'échanger entre eux du trafic Internet et est par conséquent le premier point d'échange français. Il est réparti géographiquement sur 3 sites à Paris connectés entre eux par du Giga-Ethernet. Une technologie de pointe Le réseau Renater 2 s appuie sur la technologie ATM ainsi que sur les technologies optiques. Les propriétés du protocole ATM permettent d optimiser et de gérer la qualité de service, chaque service bénéficiant de son propre réseau virtuel. ATM permet aussi de mettre en place une topologie "logique" (celle des flux et des réseaux virtuels) indépendante de la topologie "physique" (celle qui est définie par les liaisons). La topologie logique du service IP - représentée sur le schéma ci dessus - comprend des liaisons entre les régions et le système central parisien, ainsi que des liaisons directes entre régions, qui facilitent l'écoulement du trafic de voisinage, et procurent la sécurité d'une topologie maillée. La granularité permise par la technologie ATM permet d adapter au mieux les débits de la topologie logique de chaque service aux besoins des utilisateurs. Les technologies optiques, telles que le multiplexage de longueurs d'onde (DWDM) permettent d'utiliser la fibre optique à très haut débit. Elles sont utilisées en particulier dans la boucle optique qui constitue la partie francilienne à 80 Gbits/s de Renater. 1.4 Le GIP Renater Pour assurer la maîtrise complète de Renater et l'interface avec les utilisateurs, un Groupement d'intérêt Public du nom GIP Renater a été créé par les ministères an charge de l'éducation nationale et de la recherche qui se sont associés à quelques grands organismes de recherche qui sont à ce jour: le CNRS, le CEA, l'inria, le CNES, l'inra et le CIRAD. Un GIP est un organisme à but non lucratif, réunissant des administrations de l'etat et des organismes publics pour une activité définie. Dans le cas du GIP Renater, il s'agit du réseau Renater. Le GIP Renater est le maître d'ouvrage de la partie commune de Renater, constituée de son épine dorsale Renater 2 et bientôt Renater 3, des liaisons internationales, de ses actions pilotes, et du service SFINX. Il est le coordinateur technique et opérationnel global de l'ensemble du réseau Renater y compris ses éléments régionaux. Il représente le réseau Renater auprès des institutions françaises et étrangères, et notamment auprès des autres réseaux de la recherche dans le monde. Le GIP Renater est financé par les contributions de ses membres, par des subventions gouvernementales (et européennes pour certains projets spécifiques) et par les contrats passés 6
par les organismes utilisateurs non membres (y compris les ISP qui utilisent le service SFINX). Ses dépenses concernent les coûts de Renater 2 (bientôt Renater 3) et des liaisons internationales, les actions pilotes, le CERT, les services divers, les dépenses de fonctionnement, notamment les coûts liés au personnel. Le directeur du GIP Renater est M. Dany Vandromme, Professeur des Universités. L'équipe du GIP Renater comprend aujourd'hui un peu moins de 30 de personnes : ingénieurs, techniciens et personnel administratif. C'est cette équipe que j'ai intégré pendant les 6 mois de mon stage technique. 7
2 Le projet IPv6 multicast et son environnement 2.1 IPv6 et son déploiement dans Renater 2.1.1 Le protocole IPv6 IPv4 a été initialement conçu pour un réseau comprenant une centaine d'ordinateurs. Avec le web, Internet a vu son utilisation augmenter de manière exponentielle si bien que la saturation du réseau a été initialement prévue pour 1994. Des solutions comme le NAT (translation d'adresses) et le CIDR (Classless InterDomain Routing - RFC 1519) ont permis de ralentir considérablement l'explosion du réseau et ont permis de mettre au point un nouveau protocole Internet appelé IPv6. IPv6 est conçu pour remédier aux limitations de IPv4 et même temps répondre à de nouvelles exigences techniques apparues au niveau des réseaux ou des applications. La normalisation du protocole arrive aujourd'hui en bout de cycle. Voici une explication synthétique des fonctionnalités principales du protocole IPv6 : 2.1.1.1 Un plus grand nombre d'adresses IP Toutes les adresses IP ont presque été allouées et IPv6 a pour première mission d'apporter un plus grand nombre d'adresses. Une adresse IPv6 est composée de 128 bits contre 32 bits pour IPv4. Le nombre d'adresses IPv6 disponibles a été estimé entre 1 564 et 3 911 873 538 269 506 102 adresses par mètre carré (océans compris). On peut donc considérer le nombre d'adresse IPv6 comme illimité. La représentation textuelle d'une adresse IPv6 se fait en découpant le mot de 128 bits de l'adresse en 8 mots de 16 bits séparés par le caractère ":", chacun d'eux étant représenté en hexadécimal (la casse des symboles n'a pas d'importance). Par exemple: fedc:0000:0000:0000:0400:a987:6543:210f Dans un champ, il n'est pas nécessaire d'écrire les 0 placés en tête et plusieurs champs nuls consécutifs peuvent être abrégés par "::". Ce symbole ne peut apparaître qu'une seule fois dans une adresse. L'adresse précédente s'écrit donc en fait: fedc::400:a987:6543:210f 2.1.1.2 Une hiérarchisation des adresses L'objectif principal d'ipv6 a été de hiérarchiser les adresses pour permettre de plus grands agrégats et une réduction de la taille des tables de routage des routeurs de backbone. Voici le schéma d'une adresse IPv6 : 001 3 bits TLA 13 bits stla 13 bits Res 6 bits NLA 13 bits SLA 16 bits Interface ID 64 bits Topologie publique Topologie privée 8
Chaque partie est réservée à un usage précis. Il est à noter que la partie publique de l'adresse peut être encore amenée à certaines modifications. La partie privée quant à elle gardera définitivement cette structure. Les 3 premiers bits 001 sont utilisés pour identifier le format d'adresse IPv6 agrégé (aggregatable global unicast addresses). Le TLA (Top Level Aggregator) est réservé pour numéroter des opérateurs de transit. Il n'existe pas aujourd'hui d'opérateur de transit IPv6 et cette partie n'est utilisée que pour différencier certains types spécifiques d'adresses (adresses de test, adresses officielles, 6to4...) Le stla (sub TLA) permet de numéroter les différents fournisseurs d'accès IPv6. Chaque Internet Registry 1 possède une partie du subtla pour numéroter les providers de sa zone géographique. Quand l'espace d'adressage assigné est épuisé, l'internet Registry se voit confier un nouvel espace par l'iana. Les 6 bits suivants sont réservés pour pouvoir étendre la partie stla ou NLA en fonction des évolutions futures. Le NLA (Network Level Aggregator) est la partie réservée aux providers pour numéroter leurs différents clients et gérer la hierarchie au sein de leur réseau. Le SLA (Site Level Aggregator) est la partie réservée aux sites pour permettre de hiérarchiser le réseau en créant d'éventuels sous-réseaux. Les 16 bits du SLA permettent un découpage du site en 65 536 sous-réseaux ce qui permet de n'allouer, même à des sites de très grande taille qu'un seul NLA-ID (identifiant de NLA) Cette structure hiérarchique permet de pallier un des problèmes majeurs du protocole IPv4 à savoir l'explosion de la taille des tables de routage des routeurs de backbone. Par exemple, Renater compte aujourd'hui environ 4000 routes qui sont agrégées en un peu plus de 140 agrégats IPv4 et il ne suffit que de 2 préfixes IPv6 pour annoncer l'ensemble du pilote IPv6 (le préfixe de production et le préfixe de test) sur le réseau Internet IPv6. 2.1.1.3 Auto-configuration des stations Un autre objectif a été de supprimer les commandes manuelles à fournir en IPv4 (adresse IP, passerelle par défaut) pour que la connexion au réseau devienne "plug-and-play" sans avoir à configurer de serveurs supplémentaires comme les serveurs DHCP. Les 64 bits de poids fort de l'adresse IPv6 correspondent à un identifiant de réseau et les 64 bits restants sont l'identifiant d'interface qui peut être déterminé automatiquement en fonction de l'adresse physique de la machine. Une station qui démarre va émettre un paquet "router sollicitation" pour faire savoir au routeur du LAN qu'elle a besoin du préfixe du LAN pour calculer son adresse IPv6. Ce dernier répondra par un paquet "router advertisement" contenant le préfixe du LAN ainsi que d'autres informations comme la passerelle par défaut. Une station configurera son adresse IPv6 en concaténant le préfixe reçu et son identifiant d'interface qu'elle a calculé à partir de son adresse physique. 1 Un Internet Registry a la mission d'allouer des blocs d'adresses IP et des préfixes IPv6 dans sa zone géographique. Les Internet Registries aujourd'hui sont l'arin pour l'amérique du Nord (www.arin.net), l'atnic pour l'amérque du Sud (www.atnic.net), RIPE-NCC pour l'europe, l'afrique du Nord et le centre de l'asie (www.ripe.net), l'apnic pour l'asie Pacifique (www.apnic.net). L'ICANN assure la coordination des Internet Registries (www.iana.net). 9
2.1.1.4 Le routage Le routage IPv6 offre très peu de différences avec IPv4. Les protocoles de routage IPv6 les plus connus sont RIPng adaptation de RIPv2, OSPFv3, ISIS pour IPv6 et BGP4+. 2.1.1.5 La sécurité La sécurité est assurée par deux mécansimes: IPsec qui permet la confidentialité des échanges de données entre les usagers et les access-lists qui permettent de protéger les réseaux contre les intrusions. Le protocole IPv6 permet l'authentification et le chiffrement des données (AH et ESP pour IPsec). La sécurité doit être obligatoirement gérée sur toutes les piles IPv6 afin de pouvoir échanger entre tous les nœuds des informations confidentielles. La sécurité est aussi gérée en filtrant certains protocoles qui peuvent être utilisés pour attaquer le réseau. Le problème est que l'implémentation des access-lists sur les routeurs n'est pas toujours réalisée. 2.1.1.6 La qualité de service avec Diffserv (RFC 2474) Chaque pile IPv6 doit être capable d'assurer la qualité de service en routant avec différentes priorités les paquets ayant des champs diffserv différents. Chaque paquet IPv6 peut par exemple être marqué avec une priorité haute s'il doit véhiculé du trafic multimédia afin de rester un temps minimum dans les files d'attente des routeurs. Le protocole diffserv s'applique aussi bien sur IPv6 que sur IPv4. 2.1.1.7 La mobilité L'objectif est de permettre à une station de rester joignable avec la même adresse IPv6 quelque soit sa localisation dans l'internet. Des ébauches de solutions ont été mises en œuvre sur IPv4 et nécessitaient la configuration de serveurs et de stations mobiles. La mobilité est gérée directement au niveau de la couche IPv6 : chaque routeur peut être configuré en tant qu'agent mère et chaque station peut être déclarée mobile sans ajout de logiciels supplémentaires. Voici une explication synthétique de mobile IPv6. Lorsqu'une station change de réseau, elle va récupérer par le mécanisme d'autoconfiguration une nouvelle adresse IP. Ensuite, elle va avertir l'agent mère qui se situe sur son réseau mère de lui envoyer tous les paquets qui lui sont destinés. Quand un ordinateur veut joindre un mobile, il va rechercher dans le DNS l'adresse du mobile et va récupérer l'adresse permanente du mobile. Il va envoyer les paquets à cette adresse, c'est-à-dire à l'adresse du mobile quand il est sur le réseau mère. Lorsque les paquets arrivent sur le réseau mère, l'agent mère, qui a été prévenu de la nouvelle position du mobile, va faire suivre les paquets au mobile. 10
Des que le mobile reçoit le premier paquet, il donne à son correspondant son adresse courante, ce qui permet à ce dernier de joindre directement le mobile, sans passer par l'agent mère, ce qui permet une optimisation de routage. 2.1.1.8 Le multicast Chaque pile IPv6 doit obligatoirement supporter le multicast (MLD 2 ). L'objectif est de ne pas devoir créer de tunnels multicast comme ça a été le cas en IPv4. Une adresse multicast a le préfixe ff00::/8 et la structure suivante: 8 bits 4 bits 4 bits 112 bits 1111 1111 flags scope group ID F F flags est un champ pour indiquer certaines caractéristiques de l'adresse multicast. On peut indiquer s'il s'agit d'une adresse permanente (valeur 0) ou temporaire (valeur 1). De même, les ordinateurs qui veulent faire du PIM SSM 3 positionnent ce champ à 3. scope indique la portée de l'adresse IPv6. Cette fonctionnalité était gérée en IPv4 avec le champ time-lo-live. Voici les différentes valeurs que ce champ peut prendre : 0 réservé 1 nœud 2 lien 5 site 8 organisation E global F réservé group ID est l'identifiant de groupe. Certaines adresses sont prédéfinies. Ces adresses sont listées par le RFC 2375 On apprend par exemple que le groupe de tous les routeurs sur un lien est ff02::2 2.1.1.9 La cohabitation avec IPv4 Il est établi que les protocoles IPv4 et IPv6 auront à cohabiter pendant une longue période, aussi des mécanismes ont été mis en œuvre pour assurer la meilleure transition possible : Des adresses compatibles IPv4 Des équipements avec la double pile IPv4 / IPv6) Des mécanismes pour faciliter la gestion des tunnels : 6to4 (RFC 3056), tunnel brokers Des passerelles au niveau application (ALG : Application Level Gateways) 2.1.2 Le pilote IPv6 de Renater Il s'agit, dans le cadre d'une action pilote du GIP Renater, conduite par le G6, d'utiliser l'infrastructure de Renater2 pour mettre en place au minimum une connectivité IPv6 sur 2 Le multicast est expliqué plus en détail dans le chapitre 2.2 3 Protocole de routage multicast 11
l'ensemble du territoire, pour les sites prêts à expérimenter la pile protocolaire IPv6 et ses diverses implantations/applications. L'objectif pour le GIP Renater est de commencer à mettre en place les moyens nécessaires à l'allocation des ressources indispensables au raccordement des sites de tests au backbone IPv6. Il s'agit aussi de fournir la connectivité IPv6 pour de nombreux projets nationaux et internationaux qui en ont besoin. Au plan local et régional Un service de connectivité IPv6 (native ou encapsulée) est offert aux sites qui en font la demande et remplissant les critères ad hoc fixés conjointement par le GIP Renater et le G6. Un service de passerellage entre IPv6 et IPv4 sera mis en place. Au plan national Les Points d'interconnexion IPv6 Régionaux (PIR) sont raccordés entre eux par des PVC ATM déployés dans Renater 2. Ils offrent de ce fait une connectivité IPv6 nationale aux sites qui leur sont connectés. Le SFINX 4 a été connecté au pilote IPv6 de Renater afin de permettre aux fournisseurs de connectivité IPv6 d'échanger du trafic. Au plan international De nombreux projets multinationaux nécessitent des connexions avec d'autres réseaux IPv6. Des liaisons vers des réseaux IPv6 européens ont été déployées. Une connexion vers le 6TAP a été mise en place afin d'accéder au 6Bone et à d'autres réseaux IPv6 comme 6Ren. Des liaisons vers le Japon et la Corée ont été établies. Il est important d'avoir des liaisons vers ces pays qui sont les leaders dans le développement d'ipv6 à l'heure actuelle. La figure suivante est le schéma du pilote IPv6 de Renater avec les points de présence à Grenoble, Paris, Rennes, Strasbourg et Nancy (prochainement Sophia et Toulouse) et les connexions internationales: 4 Le SFINX est le point d'échange de Renater où plus de 70 fournisseurs d'accès à Internet sont connectés et y échangent du trafic (www.sfinx.tm.fr) 12
2.2 La technologie multicast IPv6 2.2.1 Généralités Les applications réseau fonctionnent pour une grande majorité dans le mode IP unicast : le poste émetteur envoie des paquets IP dont chacun porte une adresse de destination explicite. Le réseau transporte le paquet vers ce destinataire, et uniquement vers lui. En multicast (ou diffusion de groupe), le réseau fonctionne d'une source vers un ensemble de récepteurs. La source émet des paquets avec une adresse de destination qui est en fait un identifiant de groupe. Au niveau de ses routeurs IP, le réseau démultiplie les paquets de telle sorte que tous les postes récepteurs abonnés à cet instant à cette session en reçoivent chacun une copie. Prenons l'exemple suivant: une station E émet de la vidéo et 4 ordinateurs (R1, R2, R3 et R4) veulent recevoir le flux vidéo. Sur le schéma de gauche nous avons les différents flux émis avec de l'unicast et sur celui de droite nous avons le flux émis avec le multicast. Le multicast permet de consommer moins de bande passante et diminue la charge des processeurs des stations émettrices puisque ces dernières ne doivent émettre qu'un flux de données. C'est une technologie vouée à un grand avenir à l'heure où l'on parle de radio et même de télévision sur Internet. Ces diffusions se font aujourd'hui en unicast ce qui cause une grande consommation de bande passante et qui nécessite des serveurs audio et vidéo d'importante puissance. 2.2.2 Les protocoles Le multicast nécessite pour fonctionner des protocoles qui interviennent à différents niveaux. Au niveau lien-local, un premier protocole nommé MLD (Multicast Listener Discovery) est nécessaire pour que les applications s'abonnent à des groupes auprès du routeur d'accès. D'autres protocoles interviennent au niveau inter-lans. Ils permettent de créer des arbres de diffusion multicast en fonction des liens-local où il y a des abonnés. Ainsi, 13
des domaines peuvent être créés entre les LANs qui souhaitent s'échanger du trafic multicast. Des protocoles interviennent au niveau inter-domaines pour qu'il soit possible d'échanger du trafic multicast entre tous ces domaines. 2.2.2.1 Au niveau lien-local : Le protocole MLD (Multicast Listener Discovery - RFC 2710) MLD (Multicast Listener Discovery) est le protocole de dialogue entre les stations et les routeurs pour la gestion des groupes multicast. Les applications utilisent MLD pour s'abonner ou se désabonner à un groupe multicast. Ce protocole intervient donc sur les parties terminales du réseau. Les messages MLD sont véhiculés dans des paquets ICMPv6 (protocole n 58 en décimal). Sur chaque lien-local, un seul routeur peut avoir le statut de demandeur 5 MLD. C'est-à-dire que c'est le seul qui va gérer les messages MLD sur le lien-local. S'il y a plusieurs routeurs sur le lien, c'est celui qui a la plus petite adresse IPv6 qui est demandeur, tous les autres deviennent non-demandeurs. Voici la structure d'un message MLD : Type (8 bits) Code (8 bits) Checksum (16 bits) Maximum Response Delay (16 bits) Reserved (16 bits) IPv6 Multicast Address (128 bits) L'explication de chacun des champs du message est inclue dans l'explication du protocole ci-dessous. Le champ type permet d'identifier 3 types de message MLD : Multicast listener report : (Type=131 en décimal) Ce message est envoyé au groupe de tous les routeurs multicast sur le lien (ff02::2). Quand une application désire s'abonner à un groupe, elle va émettre un message multicast listener report avec un champ "IPv6 Multicast Address" qui contient l'adresse IPv6 du groupe multicast dont elle veut faire partie. Le routeur qui reçoit ce message ajoute une entrée pour le groupe multicast dans sa table MLD si elle n'existe pas déjà et commencera à diffuser sur le LAN les données à destination de ce groupe. Multicast listener done : (Type=132 en décimal). Quand une application veut quitter un groupe, elle envoie ce message au groupe des routeurs multicast (ff02::2) en spécifiant dans le champ "IPv6 Multicast Address" l'adresse IPv6 du groupe qu'elle veut quitter. Multicast listener query : (Type=130 en décimal) Il y a deux types de multicast listener query qui diffèrent par le contenu du champ "IPv6 Multicast Address" General Query : utilisé par le routeur pour connaître tous les groupes auxquels sont abonnées les différentes applications multicast sur le lien-local. Le champ "IPv6 Multicast Address" possède pour un General Query la valeur 0. Ce message est envoyé au groupe multicast de toutes les stations sur le lien-local (ff02::1) Périodiquement, le routeur demande à toutes les stations sur le lien-local (groupe multicast ff02::1) les groupes auxquels leurs applications sont abonnées. Quand elles 5 Querier en anglais 14
reçoivent ce message MLD, les stations déclenchent pour chacune des adresses multicast un compte à rebours avec une valeur initiale aléatoire (comprise entre 0 et "Maximum Response Delay" contenu dans le message MLD). Quand le compte à rebours d'une adresse est écoulé, la station envoie un message multicast listener report pour ce groupe multicast si aucun report pour ce groupe n'a été envoyé auparavant par une autre station. Ainsi, seule une réponse par groupe est donnée. A G1 G2 B G1 3 Report (G1) Report (G1) Report (G2) 2 Multicast General Query 1 Dans l'exemple ci-dessus, le routeur émet une requête générale. Des applications sur les stations A et B veulent recevoir le trafic pour le groupe G1. La station A répond la première. B voit que A a déjà répondu et annule sa réponse en attente. Si le routeur ne reçoit plus de multicast listener report pour des groupes qu'il a dans sa table MLD, il supprime alors ces groupes de sa table après un délai de l'ordre de 3 minutes. Multicast-Address-Specific Query : utilisé pour savoir s'il y a des applications abonnées à l'adresse multicast spécifique contenue dans le champ "IPv6 Multicast Address". Ce message est envoyé au groupe dont on veut savoir s'il y a des abonnés. Quand un routeur reçoit un message multicast listener done, il envoie un group-specific query afin de savoir s'il y a encore des ordinateurs sur lesquels tournent des applications abonnées à ce groupe. Si aucune machine ne répond, il efface le groupe de sa table MLD. A G2 B G1 3 Report (G1) 1 Done (G1) Multicast Specific Query (G1) 2 Dans cet exemple, une application multicast sur la station A quitte le groupe G1. Le routeur envoie un specific query pour savoir s'il y a d'autres applications abonnées au groupe G1 sur le lien. Une application multicast lancée sur B, qui est toujours abonné au groupe G1, envoie alors un report pour le groupe G1 qui n'est donc pas effacé de la table MLD du routeur. Dans le cas où seule une application sur la station A était abonnée, le routeur n'aurait pas reçu de report et aurait effacé le groupe G1 de sa table MLD. 15
2.2.2.2 Au niveau inter-lans (Domaine PIM) Les LANs qui supportent le multicast peuvent se grouper en domaines afin d'échanger entre eux du trafic multicast. Chaque domaine a une administration qui lui est propre. Les protocoles de routage multicast inter-lans ont été développés pour répondre aux problèmes suivants : Comment atteindre les membres des différents groupes de diffusion répartis sur tout un domaine (arbres d'acheminement) Comment économiser de la bande passante en n'acheminant les paquets multicast que là où il y a des abonnés (même si la bande passante n'est plus une contrainte aujourd'hui sur une grande partie du réseau qui offre une capacité suffisante) Comment optimiser les échanges entre routeurs (vaut-il mieux annoncer quels sont les groupes que l'on souhaite recevoir ou ceux que l'on ne veut pas recevoir?) On peut actuellement répartir les protocoles de routage multicast en deux familles: Ceux orientés «forte densité de clients» (dense-mode) comme DVMRP (Distance Vector Multicast Routing Protocol) qui a aujourd'hui presque disparu, et PIM-DM (Protocol Independant Multicast), plus récent. Ces protocoles supposent qu'il y a des membres des groupes multicast sur la plupart des réseaux et que l'absence de membre constitue l'exception. Dans un domaine PIM-DM, les routeurs vont inonder périodiquement tout le domaine en transmettant tous les flux multicast à leurs voisins. Les routeurs qui ne veulent pas recevoir le trafic multicast demandent à leurs voisins de cesser de leur envoyer ces flux (mécanisme de pruning ou élagage en français). C'est de cette manière qu'est créé l'arbre de diffusion. Le problème est qu'un routeur qui ne désire pas recevoir du trafic multicast va passer son temps a demander qu'on cesse de lui envoyer des flux multicast. C'est pour cela que cette approche a presque disparu pour faire place au sparse mode. Ceux orientés «faible densité de clients» (sparse-mode) comme PIM-SM (PIM Sparse- Mode). Ces protocoles supposent, au contraire des précédents, que les membres de groupe multicast sont très dispersés et peu nombreux par rapport au nombre de réseaux desservis. Un ou plusieurs points de rendez-vous sont configurés dans le domaine PIM. Ces points de rendez-vous connaissent l'ensemble des sources des différents groupes multicast du domaine. Ils permettent aux sources et aux abonnés de se rencontrer sans inonder le réseau. Le protocole PIM, comme son nom l indique, repose entièrement sur la table de routage unicast et ne nécessite pas de table de routage spécifique au protocole multicast comme c est le cas pour d autres protocoles. Ceci suppose que les topologies unicast et multicast sont identiques ce qui n est pas le cas lorsque l on a une architecture avec des tunnels. Dans ce cas, on a recours à une table de routage spécifique au protocole multicast. Pour avoir plus d'informations quant au multicast, il est vivement conseillé de lire "Developing IP Multicast Networks" de Beau Williamson aux éditions Cisco Press. C'est un ouvrage de référence sur le multicast qui décrit en détail les mécanismes compliqués du multicast. 2.2.2.3 Au niveau inter-domaines Les domaines doivent pouvoir s'échanger entre eux le trafic multicast pour qu'il soit possible de recevoir depuis n'importe quel site le trafic multicast de tout l'internet. Deux protocoles sont utilisés au niveau inter-domaine : MBGP (Multiprotocol BGP) et MSDP (Multicast Source Discovery Protocol). 16
2.2.3 Le déploiement et l'usage du multicast dans Renater Aujourd'hui, un service de transport multicast natif est déployé entre les NRD (Nœud Régional de Distribution) de Renater2 et s'appuie sur une infrastructure de réseau privé (VPN ATM) ce qui permet d'assurer une qualité de service à ces applications qui sont presque toujours de type multimédia. Le cœur du réseau multicast de Renater2 (FMBone2) est constitué d'un routeur situé dans le NIO (Nœud d'interconnexion des Opérateurs) et des différents NRD. Les routeurs multicast dans les NRD établissent des liens en utilisant les protocoles PIM Sparse Mode, MBGP, MSDP. L'exploitation du FMBone2 ainsi que sa supervision sont assurées par l'opérateur de Renater2 : CS Telecom sous le contrôle du GIP Renater. Le service multicast sur Renater2 est un service opérationnel. Des causeries ont régulièrement lieu sur le FMBone. La vidéo et l'audio sont retransmis sur le FMBone et chaque site connecté à Renater qui est configuré pour recevoir le multicast peut participer à ces visioconférences. Le programme de ces causeries est disponible à l'url suivante: http://www.univ-valenciennes.fr/cru/causeries/ Les logiciels utilisés sont vic pour la vidéo, rat pour l'audio, sdr pour l'annonce des sessions multicast et wb pour le tableau blanc sur lequel chacun peut dessiner et diffuser des schémas. Le multicast touche de plus en plus de personnes car c'est véritablement une technologie d'avenir qui sera indispensable pour la visioconférence avec de nombreux sites participants, la télé et la radio sur Internet. 2.3 Le projet IPv6 multicast 2.3.1 Définition du projet Le but initial du projet est la diffusion en multicast IPv6 du séminaire Aristote du 20 décembre 2001. Les séminaires Aristote sont diffusés d'habitude en multicast IPv4 sur le FMBone. Le projet peut se répartir en 2 tâches différentes mais tout aussi importantes: La conception d'une architecture réseau multicast IPv6 pour permettre de router les paquets multicast vers les différents sites qui en feront la demande. (équipements, topologie, protocoles de routage, déploiement ) Etude des outils de visioconférence qui supportent le multicast IPv6. (OS, logiciels, hardware ) 2.3.2 Les enjeux du projet IPv6 est considéré par beaucoup comme un protocole réseau encore à l'état de test dont l'usage est restreint au monde de la recherche. Cependant, il est notoire que les limites technologiques du protocole IPv4 sont atteintes et que le protocole IPv6 sera son successeur. L'enjeu de ce projet est de montrer qu'on est aujourd'hui capable de fournir un service réel, de haute technologie qu'est la visioconférence en multicast sur IPv6. Ce projet est en quelque sorte une manière d'assurer la promotion du protocole IPv6. 17
L'objectif est aussi d'éduquer les sites qui désirent recevoir le service multicast IPv6 à ces technologies. C'est une première étape pour intégrer le protocole IPv6, en connaître les rouages pour être prêts à déployer IPv6 sur un réseau local en mode de production. Enfin, l'objectif est de montrer aux équipementiers que nous avons besoin de cette technologie afin qu'ils implémentent le plus rapidement possible le multicast IPv6. Cette fonctionnalité n'est pas perçue comme prioritaire actuellement par les constructeurs qui n'y voient pas forcément d'intérêt commercial. 18
3 La réalisation du projet 3.1 Intégration du protocole IPv6 Dès mon arrivée au GIP Renater, ma première tâche a été de me familiariser avec le protocole IPv6. Pour cela, certaines tâches m'ont été confiées afin que je m'approprie en profondeur ce protocole. 3.1.1 Bibliographie de RFC sur IPv6 Cette bibliographie devait reprendre tous les RFC 6 sortis qui ont un rapport avec le protocole IPv6, regarder leur statut, leur importance afin de ne garder que ceux qui offrent un réel intérêt et qui sont toujours valides (certains RFC sur le protocole IPv6 sont obsolètes) La plupart des RFC qui ont un lien avec le protocole IPv6 y sont classés par ordre d'apparition, par statuts ainsi que par thèmes. Il est ainsi possible en un seul click d'avoir sous les yeux tous les RFC qui concernent les adresses IPv6. Une grande partie des RFC est résumée en français pour que le lecteur puisse rapidement cerner le contenu du document. Cette bibliographie est disponible à l'url suivante : http://mother6.renater.fr/biblio/index.html Faire cette bibliographie m'a permis de comprendre de nombreux aspects théoriques du protocole IPv6. Cela m'a aussi permis de comprendre le processus de standardisation d'un protocole. 3.1.2 Evaluation d'un équipement IPv6 La société 6wind est une société française spécialisée dans la construction de routeurs d'accès IPv6. Cette société a prêté au GIP Renater 3 routeurs pour évaluation. Il est intéressant pour un équipementier de faire connaître son matériel de cette façon. Si l'évaluation est satisfaisante, Renater pourrait ensuite conseiller aux sites des équipements 6wind pour routeur d'accès. Le GIP Renater possède actuellement comme routeur d'accès IPv6 un Cisco 4000. Ce routeur est assez ancien et il est intéressant de voir ce qu'offre le constructeur 6wind en vue d'un éventuel changement. J'ai donc établi une série importante de tests l'équipement 6wind 6211 qui portent sur les points suivants : configuration générale, routage, applications, documentation, migration, sécurité et supervision soit toutes les fonctionnalités annoncées du routeur. J'ai transmis à la société 6wind cette expertise qui a été appréciée comme un travail de "spécialistes en IPv6" et qui a été prise en compte pour le développement futur de Sixos (IOS des routeurs 6wind). 6 Tous les standards d'internet sont décrits dans les RFC ou Request for Comments. Des groupes de travail décrivent tout d'abord des nouveaux protocoles dans des drafts ou brouillons. La durée de validité d'un draft est de 6 mois. Ces drafts sont discutés au sein des groupes de travail. Quand un draft a été approuvé par l'ensemble des personnes abonnées à la mailing-list d'un groupe de travail et qu'il a fait l'objet d'au moins deux implémentations interopérables ayant donné satisfaction, le draft est proposé comme RFC. Chaque RFC a un statut qui peut être draft stadard, proposed standard, Internet standard, informational, historic De nombreuses informations sont disponibles sur le site de l'ietf www.ietf.org et dans le livre du G6. 19
Cette expertise m'a apporté une connaissance pratique du protocole IPv6 en plus des connaissances théoriques intégrées lors de la rédaction de la bibliographie. Il m'a ensuite été possible de me pencher sur le projet multicast IPv6. 3.2 La diffusion du séminaire Aristote en multicast IPv6 La réalisation du projet peut se découper en deux tâches différentes: Etude des équipements de visioconférence en multicast IPv6: Cette partie comprend l'étude des systèmes d'exploitations qui supportent IPv6 et le multicast IPv6 (MLD). Elle comprend aussi l'étude des logiciels de visioconférence en multicast IPv6 ainsi que du hardware supporté par les différents systèmes d'exploitation et logiciels. Conception d'un réseau multicast IPv6: il a été baptisé le M6Bone (par analogie à l ancien MBone pour IPv4) La conception du réseau comprend l'étude de la topologie à adopter, des protocoles de routage multicast et unicast ainsi que des équipements de routage. Cette phase nécessite une prise de contact avec toutes les personnes intéressées par l'expérimentation et qui veulent se connecter au réseau. 3.2.1 Les équipements pour une visioconférence multicast IPv6 Par manque de temps, je ne me suis consacré qu à l étude des outils de visioconférence nécessaires pour assurer la diffusion du séminaire Aristote du 20 décembre 2001. Cette partie comprenait à l origine l étude de tous les outils de visioconférence en multicast IPv6 afin d expliquer aux sites connectés comment suivre le séminaire. J ai configuré 3 stations capables de faire de la visioconférence multicast IPv6. La première sert pour la diffusion du séminaire (son et vidéo) depuis l école polytechnique. La seconde est installée au GIP Renater dans le but de faire une démonstration d une visioconférence entre l école polytechnique et le GIP Renater. La troisième station est installée dans l école polytechnique et montre en continu les images de la diffusion à l assistance. Les 2 premières stations sont des PC FreeBSD avec la pile IPv6 Kame qui possèdent les outils de visioconférence vic pour la vidéo et rat pour l audio de l UCL (University College of London). L acquisition vidéo est faite à l aide d une carte Tuner TV et d un caméscope. La gestion des ports USB sous FreeBSD n est pas assez avancée pour utiliser une webcam classique. La troisième station est un PC sous Windows 2000 avec la pile IPv6 expérimentale de Microsoft. Seul vic a été installé sur cette station car il y avait des problèmes avec rat. Ceci importe peu car cette station ne sert qu à montrer les images à l assistance. L installation des logiciels n est pas encore très simple et il existe des bugs. Le réseau établi permettra de tester ces logiciels dans des conditions plus aisées et permettra un développement rapide de toutes les applications. Les détails sur l installation de ces outils sont expliqués en annexe. 3.2.2 Etat de l'art du routage multicast IPv6 Les protocoles de routage multicast intra et inter-domaine sur IPv6 ne sont implantés sur aucun routeur commercial. Les principaux constructeurs ne voient pas là une priorité pour l'instant. Le plan de développement de Cisco annonce l'implantation du routage multicast IPv6 en fin 2002 par exemple. MLD (Multicast Listener Discovery) est implanté sur toutes les 20
piles IPv6. En effet, le multicast est utilisé en natif sur IPv6 comme par exemple par le protocoles NDP (Neighbor Discovery Protocol) qui utilise le multicast pour faire la résolution d'adresse en IPv6 (ARP en IPv4). Le routage multicast IPv6 n'a été développé que sur la pile IPv6 Kame réalisée par le consortium Wide. Le consortium Wide regroupe une centaine de sociétés japonaises, académiques et industrielles qui ont pour objectif de développer très rapidement en collaborant une pile IPv6 standard. On peut trouver dans la pile IPv6 Kame les protocoles de routage PIM Dense Mode et PIM Sparse Mode, les deux principaux protocoles de routage multicast IPv6 intra-domaines. La pile IPv6 Kame a été développée pour des systèmes d'exploitation de type BSD c'està-dire FreeBSD, NetBSD, OpenBSD et BSD/OS. Il a donc été décidé de choisir comme routeurs IPv6 multicast des PC équipés du système d'exploitation FreeBSD. C'est en effet le système d'exploitation qui est le plus complet pour IPv6 et qui offre le plus de facilités pour sa mise en œuvre. 3.2.3 Une première topologie pour assurer la diffusion du séminaire 3.2.3.1 Architecture de test Tous les équipements du réseau doivent supporter le routage multicast pour fournir ce service ce qui n est pas le cas. Tous les routeurs qui ne supportent pas le multicast ne doivent pas apparaître dans l architecture du M6Bone. Le réseau multicast IPv6 est donc un réseau de tunnels entre les PC FreeBSD qui serviront de routeurs IPv6 multicast. Ces tunnels transporteront les paquets multicast IPv6 indépendamment de l'infrastructure sous-jacente qui ne gère pas le routage multicast. La topologie choisie pour un premier temps est une topologie en étoile centrée sur un routeur multicast IPv6 basé au GIP Renater. Ceci nous permet de garder un meilleur contrôle des équipements du réseau et de pouvoir effectuer rapidement des modifications de configuration. L'architecture globale choisie pour les premiers tests est représentée sur le schéma suivant : Site de diffusion (Ecole Polytechique) Sites qui veulent suivre la vidéoconférence Routeur multicast IPv6 national PIM SM (GIP Renater) Tunnels IPv6 multicast Réseau Renater 21
3.2.3.2 Les différents cas de figure Les personnes qui voudront suivre le séminaire d'aristote en Multicast IPv6 pourront se trouver dans 3 différents cas de figure. Les sites qui voudront suivre la diffusion du séminaire seront déjà connectés au réseau IPv6. Dans ces sites, il faut ajouter un routeur multicast IPv6 connecté via un tunnel IPv6 multicast dans IPv6 unicast au routeur central. Une fois le routeur multicast IPv6 configuré, il suffit d'installer une ou plusieurs stations IPv6 avec des outils de visioconférence adaptés au multicast IPv6. Pilote IPv6 Routeur unicast IPv6 Multicast IPv6 Tunnel IPv6 multicast dans IPv6 Site distant Routeur multicast national Routeur multicast local IPv6 PC FreeBSD Les sites qui n'auront qu'une connectivité IPv4 et voudront se connecter au réseau IPv6 multicast afin de débuter avec cette technologie. Dans ces sites, il faut ajouter un routeur IPv6 multicast connecté via un tunnel IPv6 multicast dans IPv4 au routeur central. Nous attribuerons à ces sites un préfixe IPv6 de test ce qui leur permettra d'acquérir une première expérience. Ces sites ne seront pas connectés au réseau IPv6 unicast. Ils effectueront cette démarche quand ils auront acquis suffisamment d'expérience avec le protocole IPv6 en interne. Une fois le routeur multicast IPv6 configuré, il suffit d'installer une ou plusieurs stations IPv6 avec des outils de visioconférence pour le multicast IPv6. Routeur unicast IPv4 IPv4 Routeur multicast national Multicast IPv6 Tunnel IPv6 dans IPv4 Routeur local IPv6 multicast et unicast (PC FreeBSD) Site distant Pilote IPv6 22
Un utilisateur isolé qui voudra suivre la conférence alors qu'il ne dispose que d'une connectivité IPv4. Dans ce cas, aucun routeur multicast IPv6 n'est nécessaire. Le client isolé dans un site IPv4 équipé d'outils de visioconférence multicast IPv6 se connecte au routeur IPv6 national grâce à un tunnel IPv6 multicast dans IPv4. Le client effectue les requêtes MLD directement au routeur multicast national par le tunnel configuré. IPv4 Routeur unicast IPv4 Routeur multicast central Site distant Tunnel IPv6 dans IPv4 Multicast IPv6 Pilote IPv6 23
3.2.3.3 Topologie de routage multicast Nous avons choisi de déployer le protocole de routage multicast IPv6 interlans PIM Dense Mode. Nous pensions à l'origine déployer le protocole PIM Sparse Mode, presque aussi simple à déployer que PIM Dense Mode et beaucoup plus performant puisqu'il évite l'inondation périodique du réseau. Néanmoins, après des tests prolongés, nous avons noté des coupures dans les flux multicast que nous n'avons pu résoudre. Nous avons donc décidé de revenir au protocole de routage multicast PIM DM avec lequel nous n'avons jamais eu de problèmes de ce genre. Il est à noter que les tables de routage spécifiques au protocole PIM ne sont pas implémentées. Ces tables sont nécessaires lorsque l'on a des topologies unicast et multicast qui diffèrent. Dans le cas des sites déjà connectés en IPv6, le problème suivant se pose donc : Quand un routeur reçoit un paquet multicast, il effectue un RPF check. Le routeur examine l'adresse source du paquet multicast et vérifie s'il provient bien de la route en direction de la source. Si c'est le cas, le paquet est forwardé; sinon, il est jeté. Au niveau des équipements multicast IPv6, une route vers une source qui est sur un site distant doit être vue dans le tunnel pour que le RPF check soit validé puisque tout le trafic multicast doit passer par les tunnels IPv6 multicast établis. Le préfixe du site distant doit donc être annoncé par l'interface tunnel dans la table de routage. Par contre, un problème se pose pour l'établissement du tunnel. En effet, l'extrémité du tunnel qui est l'adresse du routeur multicast IPv6 du site distant serait routée dans le tunnel. Ceci n'est évidemment pas possible puisqu'on a alors une encapsulation à l'infini des paquets dans le tunnel. L'extrémité du tunnel doit être routée à travers le réseau IPv6 unicast. L'absence de table de routage multicast spécifique au protocole de routage multicast utilisé nous impose de régler ce problème en ajoutant des routes statiques à la table de routage unicast. Pour résoudre ce problème, nous avons choisi de déclarer une route statique vers la sortie du tunnel qui passe par le routeur IPv6 unicast. Grâce à cette solution, on est sûr que l'extrémité du tunnel sera bien routée par le réseau IPv6 unicast et qu'il est correctement établi. Il ne sera pas possible d'utiliser les applications multicast sur cette machine sans engendrer de problèmes au niveau du RPF check. Il faut donc utiliser des machines distinctes (un PC pour le routeur multicast IPv6 et d'autres PC pour lancer les applications multicast IPv6) Les protocoles de routage multicast inter-domaines (MBGP et MSDP) ne sont pas développés. Il est donc impossible d'avoir pour le moment un réseau IPv6 multicast à l'échelle de la planète avec de nombreux sites connectés. Le réseau conçu permettra de montrer qu'il y a un besoin pour le multicast IPv6 et que des protocoles de routage multicast inter-domaines sont nécessaires. 3.2.3.4 Topologie de routage unicast Le protocole de routage PIM se base uniquement la table de routage unicast (les tables de routage spécifiques au protocole de routage multicast n'étant pas encore implémentées). Tous les routeurs multicast IPv6 doivent voir tous les sites du M6Bone par les tunnels multicast établis. Une première solution aurait été de configurer un ensemble de routes statiques vers chacun des sites du M6Bone ce qui a été fait dans un premier temps pour une série de tests. 24