|
|
| (79 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| | =Table des matières= | | =Table des matières= |
| | | | |
| | + | ==Actions== |
| | + | |
| | + | *Relecture: |
| | + | ** Bruno di Gennaro: 4 premiers chapitres (adressage, protocole, ND, nommage) |
| | + | |
| | + | * Court terme -> 28/2 |
| | + | ** passer les chapitres <span style="text-decoration: line-through">IPv6</span>,<span style="text-decoration: line-through"> ND</span>, <span style="text-decoration: line-through">Nommage</span> en production |
| | + | ** Faire un plan pour Routage, Intégration, Sécurité supervision |
| | + | ** Ajuster le chapitre auto-conf |
| | + | ** <span style="text-decoration: line-through">Question Luc Saccavini sur participation à l'historique</span>: OK |
| | + | ** <span style="text-decoration: line-through">Question Pierre Françon sur gestion du chapitre sécurité</span>: Non |
| | + | |
| | + | * Moyen Terme -> 14/7 |
| | + | ** Revoir DHCPv6 |
| | + | ** Thanh Luu: récuperer des adresses au RIPE NCC |
| | + | ** Revoir les exemples des premiers chapitres |
| | + | ** Remettre a jour : Support de transmission (6LoWPAN) |
| | + | ** Contenu Routage, Intégration, Sécurité, Supervision |
| | + | |
| | + | * Long terme |
| | + | ** Mobilité |
| | + | |
| | + | Fixer une reunion en Mars. |
| | + | |
| | + | ---- |
| | ''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.'' | | ''Cette partie du livre est en chantier, certaines parties sont (ou seront) plus à jour que l'[[Table des matières|édition originale]], mais quand les articles seront complets, ils remplacerons ceux de la 4ieme édition.'' |
| | | | |
| Line 20: |
Line 45: |
| | | | |
| | = Adressage (Laurent Toutain) = | | = Adressage (Laurent Toutain) = |
| − | * [[AdressageBis-Fondamentaux|Aspects Fondamentaux de l'Adressage]]
| + | |
| − | * [[AdressageBis-MeO|Mises en Oeuvre]]
| + | ''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme'' |
| − | * [[AdressageBis-Questions|Questions Ouvertes]]
| + | |
| − | * [[AdressageBis-Recherches|Problèmes de Recherche]]
| + | |
| − | * [[AdressageBis-Historique|Historique]]
| + | |
| − | * [[AdressageBis-Références|Références]]
| + | |
| − | * [[AdressageBis-Questions|Questionnaire]]
| + | |
| | | | |
| | = Protocoles réseau et transport (Laurent Toutain) = | | = Protocoles réseau et transport (Laurent Toutain) = |
| − | * [[Format du paquet IPv6]]
| + | ''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme'' |
| − | * [[Format du message ICMPv6]]
| + | |
| − | * [[Exemples de paquets]]
| + | |
| | | | |
| | = Configuration automatique et contrôle (Laurent Toutain) = | | = Configuration automatique et contrôle (Laurent Toutain) = |
| − | * [[Protocole de Découverte des voisins]]
| + | ''Ce chapitre est passé dans la table des matières de l'édition courante. Attention aux modifications de forme'' |
| − | * [[DHCPv6]]
| + | |
| − | * [[Mise en oeuvre de la configuration automatique]]
| + | |
| − | * [[Bonnes pratiques de la configuration automatique]]
| + | |
| − | * [[Activités de recherche sur la configuration automatique]]
| + | |
| − | * [[Questionnaire sur la configuration automatique]]
| + | |
| | | | |
| | = [[NommageBis|Nommage]] (Mohsen Souissi) = | | = [[NommageBis|Nommage]] (Mohsen Souissi) = |
| | | | |
| | = Supports de transmission (Laurent Toutain) = | | = Supports de transmission (Laurent Toutain) = |
| − | = Routage = | + | = Routage (Alain Bidaud) = |
| − | Pour initier une session multicast, le groupe de récepteurs intéressés, appelé aussi groupe multicast, doit être formé. Un groupe multicast est identifié par une adresse IP multicast. Chaque adresse a une portée spécifique, qui limite la propagation du trafic multicast.
| + | |
| | | | |
| − | Dans ce chapitre, nous commençons par détailler le format des adresses multicast IPv6 Nous examinons ensuite successivement l'allocation des adresses multicast IPv6 puis l'annonce des sessions.
| + | A discuter dans le groupe des rédacteurs : |
| | | | |
| − | = Multicast =
| + | Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF) |
| | | | |
| − | ==Format des adresses multicast IPv6==
| + | Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait |
| | | | |
| − | ===Généralités ===
| + | - une première partie destinée aux ISP |
| | | | |
| − | Cette section décrit le système d'adressage multicast IPv6. La figure Structure de l'adresse IPv6 Multicast donne le format de l'adresse IPv6 de multicast décrite dans le RFC 3513.
| + | - une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...) |
| | | | |
| − | [[image:CS99.gif]]
| |
| | | | |
| − | Les adresses multicast IPv6 sont dérivées du préfixe <tt>FF00::/8</tt>. Le champ drapeaux de 4 bits est défini de la manière suivante :
| + | Ajouter RPSLng (déclaration des politiques de routage dans les IRR) |
| | | | |
| − | * Seul le bit <tt>T</tt> (comme ''Transient'') du champ drapeaux est initialement décrit dans le RFC 3513. La valeur <tt>0</tt> indique une adresse multicast bien connue gérée par une autorité. La valeur <tt>1</tt> indique une valeur temporaire.
| + | Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...) |
| − | * Les bits <tt>P</tt> et <tt>R</tt> sont décrits dans le RFC 3306 et le draft Internet sur embedded-RP (RFC 3956).
| + | |
| − | * Le bit de poids fort du champ drapeaux n'est pas encore attribué.
| + | |
| | | | |
| − | Le champ drapeaux permet de définir plusieurs types d'adresses multicast IPv6 qui seront décrits dans les sections suivantes.
| |
| | | | |
| − | Le champ scope de l'adresse multicast IPv6 permet d'en limiter la portée (''scope'' en anglais). En IPv4, la portée d'un paquet est limitée par le champ TTL (''Time To Live''), de même des préfixes peuvent être définis pour identifier des adresses à portée réduite. Les valeurs suivantes sont définies :
| + | Recherche |
| | | | |
| − | * 1 - node-local
| + | Résoudre le problème du MH |
| − | * 2 - link-local
| + | |
| − | * 3 - subnet-local
| + | |
| − | * 4 - admin-local
| + | |
| − | * 5 - site-local
| + | |
| − | * 8 - organisation-local
| + | |
| − | * E - global
| + | |
| − | * Les portées 0 et F sont réservées.
| + | |
| | | | |
| − | ===Adresses multicast IPv6 permanentes===
| + | * LISP |
| | + | * Shim6/SCTP/MPTCP |
| | + | * HIP |
| | | | |
| − | Une adresse multicast IPv6 avec le bit <tt>T</tt> du champ drapeaux à <tt>0</tt> correspond à une adresse multicast permanente, allouée par l'IANA.
| + | ----- |
| | + | Bruno: VRRP, |
| | | | |
| − | [[image:CS100.gif]] | + | = Multicast = |
| | + | * [[Adressage multicast]] |
| | + | * [[Le multicast IPv6 sur le lien-local]] |
| | + | * [[PIM]] |
| | + | * [[Multicast IPv6 inter-domaine]] |
| | + | * [[Déploiement du multicast]] |
| | + | * [[Coexistence avec le multicast IPv4]] |
| | + | * [[Etude pratique du déploiement du multicast IPv6]] |
| | + | * [[Exemples de configuration dans un routeur Cisco]] |
| | | | |
| − | Lorsque le multicast IPv6 sera déployé à grande échelle, certains organismes pourraient avoir des émissions permanentes. Des chaînes de télévision ou stations de radio pourront par exemple se voir attribuer des adresses permanentes par l'IANA dans le préfixe <tt>FF00::/12</tt>.
| + | = Sécurité (TBD) = |
| | | | |
| − | Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :
| + | = [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) = |
| | | | |
| − | * des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP,...) et
| + | = [[IntegrationBis|Intégration d'IPv6 et des applications (Bruno Stévant)]] = |
| − | * des adresses correspondant d'avantage à des services applicatifs commerciaux permanents comme la distribution des chaînes de télévision. Le RFC 3307 définit des procédures pour l'allocation des adresses multicast permanentes. Celles-ci seront décrites par la suite.
| + | |
| | | | |
| − | ===Adresses temporaires=== | + | = [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) = |
| | | | |
| − | Les adresses temporaires sont des adresses multicast IPv6 dont le bit T est positionné à 1. Il existe plusieurs types d'adresses temporaires :
| + | = Supervision (Jean-Jacques Broussat) = |
| | + | = Historique de la standardisation d’IPv6 = |
| | + | = Bases whois= |
| | + | = Bibliographie = |
| | | | |
| − | * générales : Ce sont des adresses avec tous les bits du champ flag à 0 sauf le bit T positionné à 1. Il n'y a pas de recommandations pour l'utilisation de ces adresses. Des scénarios d'utilisation peuvent être, par exemple, les visioconférences ponctuelles.
| + | ---- |
| − | * dérivées d'un préfixe unicast IPv6. Le RFC 3306 définit une méthode pour dériver une adresse multicast IPv6 à partir d'un préfixe unicast :
| + | |
| − | [[image:CS101.gif]]
| + | |
| − | ** <tt>res</tt> (''reserved'') : tous les bits de ce champ doivent être positionnés à <tt>0</tt>.
| + | |
| − | ** <tt>Plen</tt> (''prefix length'') : ce champ contient la longueur du préfixe unicast utilisé pour en dériver une adresse multicast.
| + | |
| − | ** <tt>prefix</tt> : ce champ contient la valeur du préfixe du réseau utilisé pour en dériver une adresse multicast.
| + | |
| − | ** <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre [[Adressage multicast#Identifiant de groupe|Identifiant de groupe]].
| + | |
| − | : Par exemple, une adresse multicast peut être dérivée à partir du préfixe de RENATER (<tt>2001:660::/32</tt>). Le champ <tt>prefix</tt> prend la valeur <tt>2001:0660:0000:0000</tt> et le champ <tt>Plen</tt>, la valeur <tt>0x20</tt> (32 en décimal). Les adresses multicast IPv6 à choisir seront de type <tt>FF3X:20:2001:660::aabb:ccdd</tt> (<tt>aabb:ccdd</tt> étant le group-ID choisi dans l'exemple).
| + | |
| − | : Cette méthode permet la création potentielle de 232 adresses par préfixe.
| + | |
| − | * <div id="embedded">les adresses multicast "Embedded-RP" voir le RFC 3618 définit une méthode pour inclure l'adresse du RP (Point de Rendez-Vous servant à la construction de l'arbre multicast) dans l'adresse multicast IPv6. Le schéma Structure d'une adresss IPv6 Multicast "embedded RP" montre la structure d'une telle adresse, aussi appelée adresse "embedded-RP" :</div>
| + | |
| | | | |
| − | [[image:CS102.gif]]
| + | Old Stuff: chapters removed from the previous edition. |
| | | | |
| − | : Ainsi pour un point de rendez-vous qui possède l'adresse <tt>2001:660:3307:125::3</tt>, une adresse multicast correspondante peut être dérivée de la façon suivante :
| + | = Adressage = |
| | + | *[[Adressage|Généralités]] |
| | + | *[[Plans d'adressage]] |
| | + | *[[Unicast Global|Adresses Globales]] |
| | + | *[[Lien-local|Adresses Lien-local]] |
| | + | *[[Identifiant d'interface]] |
| | + | *[[Site-local]] |
| | + | *[[Autres types d'adresses]] |
| | + | *[[Exemple Unicast|Exemple d'utilisation des adresses unicast]] |
| | + | *[[Anycast]] |
| | | | |
| − | ** <tt>res</tt> (Reservé) : Les 4 bits de ce champ sont positionnés à <tt>0</tt>. | + | = Protocoles réseau et transport = |
| − | ** <tt>RPad</tt> : Ce champ contient les 4 derniers bits de l'adresse du RP. Dans cet exemple, <tt>RPad</tt> prend la valeur 3. | + | * [[IPv6]] |
| − | ** <tt>Plen</tt> (Longueur du préfixe) : Ce champ contient la longueur du préfixe réseau du RP à prendre en compte. Dans cet exemple, la valeur est de <tt>0x40</tt> (soit 64 en décimal), | + | **Champs particuliers |
| − | ** <tt>prefix</tt> (Préfixe) : Ce champ contient le préfixe réseau du RP. Ici, cette valeur est <tt>2001:660:3007:125</tt> | + | ***[[Classe de trafic]] |
| − | ** <tt>group-ID</tt> : ce champ de 32 bits contient l'identifiant de groupe, détaillé au chapitre [[Adressage multicast#Identifiant de groupe|Identifiant de groupe]]. | + | ***[[Identificateur de flux]] |
| − | : Une adresse multicast dérivée de ce point de rendez-vous sera donc de la forme <tt>FF7X:340:2001:660:3007:125:aabb:ccdd</tt> (<tt>aabb:ccdd</tt> étant le group-ID choisi dans cet exemple).
| + | **[[Justification des extensions]] |
| − | * Les adresses SSM (''Source Specific Multicast'') sont décrites également dans le RFC 3306. Si le préfixe <tt>FF3X::/32</tt> a été réservé pour les adresses multicast SSM, seules les adresses dérivées du préfixe <tt>FF3X::/96</tt> doivent être utilisées dans un premier temps. Ce sont des adresses multicast basées sur le préfixe unicast où les champs <tt>Plen</tt> et <tt>prefix</tt> sont positionnés à 0 (cf. figure Structure des adresses IPv6 Multicast SSM). | + | **[[Les extensions]] |
| | + | **[[Exemples d'extensions]] |
| | + | **[[Checksum au niveau transport]] |
| | + | *[[ICMPv6]] |
| | + | *[[Protocoles de Niveau 4]] |
| | | | |
| − | [[image:CS103.gif]] | + | = Configuration automatique et contrôle = |
| | + | * [[Découverte de voisins]] |
| | + | ** [[Exemples de découverte de voisins]] |
| | + | * [[Configuration automatique]] |
| | + | ** [[Exemples de configuration sans état]] |
| | + | * [[Configuration avec état :DHCPv6]] |
| | + | * [[Renumérotation des routeurs]] |
| | + | * [[Mécanisme de découverte du PMTU]] |
| | | | |
| − | Le tableau Récapitulatif des types d'adresses multicast définis récapitule les préfixes associés aux differents types d'adresses multicast décrit précédement.
| + | = [[Nommage]] = |
| − | | + | * [[Nommage direct : du nom vers les adresses]] |
| − | {|
| + | * [[Nommage inverse : de l'adresse vers les noms]] |
| − | |+ Récapitulatif des types d'adresses multicast définis
| + | * [[Logiciels DNS supportant IPv6 et configurations]] |
| − | ! Préfixe || Usage
| + | * [[Les solutions expérimentales A6 et bitstring labels]] |
| − | |-
| + | * [[Recommandations opérationnelles pour l'intégration d'IPv6]] |
| − | |FF0X::/16 || Adresses IPv6 multicast permanentes
| + | * [[Découverte de la liste de serveurs DNS récursifs]] |
| − | |-
| + | * [[Propagation et mise à jour dynamique du DNS]] |
| − | |FF1X::/16 || Adresses IPv6 multicast temporaires générales
| + | |
| − | |-
| + | |
| − | |FF3X::/16 || Adresses multicast dérivées d'un préfix unicast (temporaires)
| + | |
| − | |-
| + | |
| − | |FF3X::/96 || Adresses SSM (temporaires)
| + | |
| − | |-
| + | |
| − | |FF7X::/16 || Adresses IPv6 multicast "Embedded-RP" (temporaires)
| + | |
| − | |}
| + | |
| − | | + | |
| − | ===Identifiant de groupe=== | + | |
| − | | + | |
| − | Le RFC 3307 décrit des procédures de création d'un identifiant de groupe (<tt>Group-ID</tt>) et le RFC 3513 fixe la taille du champ <tt>Group-ID</tt> à 112 bits. Le RFC 3307 précise également la correspondance entre les adresses IPv6 multicast et les adresses de niveau 2 : les 32 derniers bits de l'adresse multicast IPv6 sont ajoutés au préfixe MAC 33-33.
| + | |
| − | | + | |
| − | Par exemple, l'adresse FF0E:30:2001:660:3001:4002:'''AE45:2C56''' correspondra à l'adresse MAC 33-33-'''AE-45-2C-56'''. La probabilité que deux adresses multicast IPv6 utilisées sur un même lien correspondent à la même adresse MAC existe mais est très faible et les conséquences minimes. Restreindre le champ group-ID à 32 bits a toutefois un intérêt car cela apporte une homogénéité entre les différents types d'adresses décrits précédemment. En effet, dans le cas des adresses dérivées d'un préfixe unicast, ce champ a une longueur de 32 bits.
| + | |
| − | | + | |
| − | Le RFC 3307 définit aussi les adresses IPv6 multicast et identifiants de groupe qui seront gérés par l'IANA, où réservés pour des allocations dynamiques.
| + | |
| − | | + | |
| − | {|
| + | |
| − | |+Récapitulatif des usages des identifiants de groupe
| + | |
| − | ! || Description || Valeur minimale de l'identifiant de groupe || Valeur maximale de l'identifiant de groupe
| + | |
| − | |-
| + | |
| − | |Adresse multicast permanente|| C'est une adresse allouée par l'organisme IANA. Les bits P et T doivent être initialisés à zéro. || 0x00000001 || 0x3FFFFFFF
| + | |
| − | |-
| + | |
| − | |Identifiant de groupe permanent || Le but de ces identifiants de groupe est de pouvoir identifier un service donné dans un réseau. Ces services sont définis par des Group-ID alloués par l'IANA et devraient être utilisées pour des adresses IPv6 multicast dérivées d'un préfixe unicast (RFC 3306). Avec cette méthode, il est théoriquement possible d'atteindre un service donné dans n'importe quel réseau. || 0x40000000 || 0x7FFFFFFF
| + | |
| − | |-
| + | |
| − | |Adresse multicast dynamique || Les adresses multicast allouées dynamiquement doivent avoir un group-ID compris entre 0x80000000 et 0xFFFFFFFF. Ces adresses ont le bit T du champ drapeaux positionné à 1. || 0x80000000 || 0xFFFFFFFF
| + | |
| − | |}
| + | |
| − | | + | |
| − | {{suivi| Multicast | Multicast | Le multicast IPv6 sur le lien-local | Le multicast IPv6 sur le lien-local}}
| + | |
| − | | + | |
| − | ==Le multicast IPv6 sur le lien-local==
| + | |
| − | | + | |
| − | ===Gestion des abonnements sur le lien-local : MLD===
| + | |
| − | | + | |
| − | Pour offrir un service de distribution multicast, deux composants sont nécessaires : un protocole de gestion de groupe multicast et un protocole de construction d'arbre multicast. Le protocole de gestion de groupe multicast réalise la signalisation entre l'hôte et son routeur d'accès à l'Internet. En IPv6, ce protocole est MLD (''Multicast Listener Discovery''). Il est utilisé par un routeur de bordure IPv6 pour découvrir la présence de récepteurs multicast sur ses liens directement attachés, ainsi que les adresses multicast concernées.
| + | |
| − | | + | |
| − | MLD est un protocole asymétrique qui spécifie un comportement différent pour les hôtes et les routeurs multicast. Toutefois, pour les adresses multicast sur lesquelles un routeur lui-même écoute, il doit exécuter les deux parties du protocole et répondre à ses propres messages.
| + | |
| − | | + | |
| − | Comme MLD est un sous-protocole d'ICMPv6, les messages MLD sont des messages ICMPv6 particuliers. Ils sont envoyés avec :
| + | |
| − | | + | |
| − | * une adresse source IPv6 lien-local ;
| + | |
| − | * le champ "nombre de sauts" fixé à 1 ;
| + | |
| − | * l'option "IPv6 Router Alert" activée.
| + | |
| − | | + | |
| − | Cette dernière option est nécessaire afin de contraindre les routeurs à examiner les messages MLD envoyés à des adresses multicast par lesquelles les routeurs ne sont pas intéressés. La version d'origine du protocole MLD (RFC 2710) (que nous appellerons également MLDv1) présente les mêmes fonctionnalités que le protocole IGMPv2 en IPv4.
| + | |
| − | | + | |
| − | Trois types de messages sont utilisés. Leur format est donné sur la figure Format générique d'un message ICMP pour MLD:
| + | |
| − | | + | |
| − | [[image:CS104.gif]] | + | |
| − | | + | |
| − | * recensement des récepteurs multicast (type = 130) avec deux sous-types de messages :
| + | |
| − | * recensement général émis à l'adresse de diffusion générale sur le lien (<tt>FF02::1</tt>) | + | |
| − | * recensement spécifique à une adresse multicast, l'adresse de destination est l'adresse multicast du groupe en question
| + | |
| − | * rapport d'abonnement multicast (type = 131), l'adresse de destination est l'adresse multicast du groupe en question
| + | |
| − | * résiliation d'abonnement multicast (type = 132), émis à l'adresse du groupe multicast "tous les routeurs du lien local" (<tt>FF02::2</tt>).
| + | |
| − | | + | |
| − | Les champs ont la signification suivante :
| + | |
| − | | + | |
| − | * type : prend la valeur 130, 131 ou 132.
| + | |
| − | * code : mis à zéro par l'émetteur et ignoré par les récepteurs
| + | |
| − | * checksum : celui du protocole ICMPv6 standard, couvrant tout le message MLD auquel s'ajoutent les champs du pseudo-en-tête IPv6
| + | |
| − | * délai maximal de réponse :
| + | |
| − | ** utilisé seulement dans les messages de recensement. Il exprime le retard maximal autorisé (en millisecondes) pour l'arrivée des rapports d'abonnement
| + | |
| − | ** dans les messages de rapport ou de résiliation d'abonnement ce champ est mis à zéro par l'émetteur et ignoré par les récepteurs
| + | |
| − | * inutilisé : mis à zéro par l'émetteur et ignoré par les récepteurs
| + | |
| − | * adresse multicast :
| + | |
| − | ** pour un message de recensement général ce champ est mis à zéro
| + | |
| − | ** pour un message de recensement spécifique il contient l'adresse multicast en question
| + | |
| − | ** pour les messages de rapport et de résiliation d'abonnement, le champ contient l'adresse multicast sur laquelle l'hôte souhaite écouter ou cesser d'écouter
| + | |
| − | | + | |
| − | ===Messages de recensement et rapports d'abonnement périodiques MLD===
| + | |
| − | | + | |
| − | Le routeur envoie régulièrement des messages de recensement général à l'adresse de diffusion générale sur le lien (<tt>FF02::1</tt>). Les hôtes arment un temporisateur pour chaque adresse multicast qui les concerne. Si un temporisateur expire sans que l'hôte ait entendu une réponse d'un de ses voisins concernant la même adresse, il envoie un rapport d'abonnement à l'adresse multicast du groupe. Ce système de temporisateurs permet aux hôtes de surveiller les rapports des autres hôtes sur le lien et d'annuler leurs propres rapports concernant les mêmes adresses. Ainsi la quantité du trafic MLD peut être minimisée.
| + | |
| − | | + | |
| − | ===Rapports d'abonnements MLD non-sollicités===
| + | |
| − | | + | |
| − | Les changements d'état des hôtes sont notifiés par des messages non-sollicités :
| + | |
| − | | + | |
| − | * Pour souscrire à une adresse multicast spécifique, un hôte envoie un rapport d'abonnement non-sollicité ; | + | |
| − | * Pour cesser d'écouter sur une adresse multicast, l'hôte peut simplement ne plus répondre aux messages de recensement du routeur. S'il est le seul récepteur de cette adresse multicast sur le lien, après un certain temps l'état du routeur concernant cette adresse expire. Le routeur arrêtera de faire suivre les paquets multicast envoyés à l'adresse en question, s'il s'avère que l'hôte était le dernier concerné par l'adresse multicast sur le lien;
| + | |
| − | * La résiliation rapide est aussi une possibilité offerte par MLDv1. L'hôte envoie un message de résiliation d'abonnement à l'adresse multicast de "tous les routeurs du lien local" (<tt>FF02::2</tt>). Le routeur répond avec un message de recensement spécifique à l'adresse en question. S'il n'y a plus de récepteur pour répondre à ce recensement, le routeur efface l'adresse multicast de sa table de routage.
| + | |
| − | | + | |
| − | Il est possible d'avoir plusieurs routeurs multicast sur le même lien local. Dans ce cas un mécanisme d'élection est utilisé pour choisir le routeur recenseur. Celui-ci sera le seul responsable pour l'envoi des messages de recensement.
| + | |
| − | | + | |
| − | {{suivi| Adressage multicast | Adressage multicast | Exemples de fonctionnement de MLDv1 | Exemples de fonctionnement de MLDv1}}
| + | |
| − | | + | |
| − | | + | |
| − | ===Gestion des abonnements sur le lien-local : MLD version 2===
| + | |
| − | | + | |
| − | La nouvelle version du protocole de gestion de groupe multicast, MLDv2 est décrite dans le RFC 3810. Elle implante les fonctionnalités du protocole IGMPv3 défini pour IPv4, la plus importante étant l'introduction du filtrage des sources. Un hôte peut désormais spécifier les sources qu'il veut ou qu'il ne veut pas écouter pour une adresse multicast donnée. Cette information peut être utilisée par les protocoles de routage multicast afin d'éviter l'acheminement des paquets multicast provenant de certaines sources vers des liens où il n'y a pas de récepteur intéressé.
| + | |
| − | | + | |
| − | Pour être en mesure de supporter les fonctionnalités de MLDv2, l'API de l'hôte doit permettre l'opération suivante (ou un équivalent logique de celle-ci) :
| + | |
| − | | + | |
| − | EcouteIPv6Multicast (socket, interface,
| + | |
| − | adresse multicast IPv6, mode de filtrage,
| + | |
| − | liste de sources)
| + | |
| − | | + | |
| − | Par cet appel, une application demande, pour une certaine adresse multicast, la réception de paquets sur une certaine interface, en tenant compte du mode de filtrage et de la liste des sources spécifiées. Le mode de filtrage peut être soit INCLUDE, soit EXCLUDE :
| + | |
| − | | + | |
| − | * En mode INCLUDE, la réception des paquets envoyés à l'adresse multicast spécifiée est demandée seulement pour ceux en provenance des sources présentes dans la liste qui suit
| + | |
| − | * En mode EXCLUDE, la réception des paquets est demandée pour toutes les sources, à l'exception de celles spécifiées dans la liste de sources
| + | |
| − | | + | |
| − | Il existe deux types de messages MLDv2 :
| + | |
| − | | + | |
| − | * recensement des récepteurs multicast (type=130)
| + | |
| − | * rapport d'abonnement multicast version 2 (type=143)
| + | |
| − | | + | |
| − | Pour garder l'interopérabilité avec la version précédente de MLD, les messages de rapport d'abonnement multicast version 1 et de résiliation d'abonnement multicast sont également supportés.
| + | |
| − | | + | |
| − | ====Messages de recensement MLDv2====
| + | |
| − | | + | |
| − | Un message de recensement des récepteurs en MLDv2 est donné sur la figure Format d'un message de recensement MLDv2. Les champs ont la signification suivante :
| + | |
| − | | + | |
| − | [[image:CS105.gif]] | + | |
| − | | + | |
| − | * <tt>type</tt> : le même type qu'en MLDv1 | + | |
| − | * <tt>code</tt> : mis à zéro par l'émetteur et ignoré par les récepteurs
| + | |
| − | * <tt>checksum</tt> : calculé de la même façon que pour la version précédente du protocole
| + | |
| − | * <tt>délai max. de réponse</tt> : utilisé pour calculer le délai maximal de réponse durant lequel le récepteur doit envoyer éventuellement son rapport d'abonnement
| + | |
| − | * <tt>inutilisé</tt> : mis à zéro par l'émetteur et ignoré par les récepteurs,
| + | |
| − | * <tt>adresse multicast</tt>,
| + | |
| − | * <tt>réservé</tt> : mis à zéro par l'émetteur et ignoré par les récepteurs,
| + | |
| − | * drapeau <tt>S</tt> : indique aux routeurs multicast qui reçoivent ce message s'ils doivent ou pas supprimer la mise à jour des temporisateurs, effectuée normalement au moment de la réception d'un message de recensement,
| + | |
| − | * <tt>QRV</tt> : contient la variable de robustesse utilisée par le recenseur (le nombre de fois qu'un récepteur envoie un rapport pour être robuste aux pertes dans le réseau),
| + | |
| − | * <tt>QQIC</tt> : code utilisé pour calculer l'intervalle de recensement,
| + | |
| − | * <tt>nombre de sources</tt>,
| + | |
| − | * <tt>adresse de la source [N]</tt>, vecteur contenant la liste éventuelle des sources.
| + | |
| − | | + | |
| − | Trois types de messages de recensement de récepteurs multicast sont utilisés :
| + | |
| − | | + | |
| − | * recensement général envoyé par un routeur multicast afin de découvrir les adresses multicast pour lesquelles il y a des récepteurs sur ses liens directs. Dans un tel message les champs "adresse multicast" et "nombre de sources" sont mis à zéro
| + | |
| − | * recensement spécifique à une adresse multicast envoyé par un routeur multicast afin de découvrir l'existence de récepteurs pour une adresse multicast spécifique. Le champ "adresse multicast" contient l'adresse en question, tandis que le champ "nombre de sources" est mis à zéro
| + | |
| − | * recensement spécifique à une adresse multicast et à une source envoyé par un routeur multicast afin de découvrir l'existence de récepteurs pour une adresse multicast et une source spécifiques. Le champ "adresse multicast" contient l'adresse en question, tandis que les champs "adresse source [i]" forment un vecteur de N adresses unicast (valeur spécifiée dans le champ "nombre de sources").
| + | |
| − | | + | |
| − | Les messages de recensement général sont envoyés à l'adresse de diffusion générale sur le lien (<tt>FF02::1</tt>). Les autres messages de recensement sont envoyés à l'adresse multicast spécifiée dans l'en-tête MLDv2.
| + | |
| − | | + | |
| − | ===== Rapports d'abonnement MLDv2 =====
| + | |
| − | | + | |
| − | Un rapport d'abonnement multicast en MLDv2 est donné sur la figure Format d'un message de rapport d'abonnement MLDv2. Les champs ont la signification suivante :
| + | |
| − | | + | |
| − | [[image:CS106.gif]]
| + | |
| − | | + | |
| − | * <tt>type</tt>, type=143 | + | |
| − | * <tt>réservés</tt>, mis à zéro par l'émetteur et ignorés par les récepteurs
| + | |
| − | * <tt>checksum</tt>, calculé de la même façon que pour la version précédente du protocole
| + | |
| − | * <tt>nombre d'enregistrements d'adresse multicast</tt>
| + | |
| − | * <tt>enregistrement d'adresse multicast</tt> : chaque enregistrement d'adresse multicast a la forme donnée sur la figure Format d'un message de recensement MLDv2 : Les champs ont la signification suivante :
| + | |
| − | | + | |
| − | [[image:CS107.gif]] | + | |
| − | | + | |
| − | ** type d'enregistrement : plusieurs types d'enregistrements d'adresse multicast peuvent être inclus dans un rapport d'abonnement :
| + | |
| − | ::un "enregistrement d'état actuel" est envoyé par un hôte en réponse à un message de recensement. Il décrit l'état de l'hôte concernant une adresse multicast spécifique .Le champ "type d'enregistrement" peut dans ce cas avoir les valeurs <tt>MODE_IS_INCLUDE</tt> ou <tt>MODE_IS_EXCLUDE</tt>,
| + | |
| − | ::un "enregistrement de changement de mode de filtrage" est envoyé par un hôte chaque fois qu'un appel <tt>EcouteIPv6Multicast</tt> modifie son mode de filtrage pour une adresse multicast précise. Le champ "type d'enregistrement" peut dans ce cas avoir les valeurs <tt>CHANGE_TO_INCLUDE_MODE</tt> ou <tt>CHANGE_TO_EXCLUDE_MODE</tt>,
| + | |
| − | ::un "enregistrement de changement de la liste des sources" est envoyé par un hôte quand un appel <tt>EcouteIPv6Multicast</tt> modifie la liste des sources qu'il souhaite ou ne souhaite pas écouter pour une adresse multicast précise. Le champ "type d'enregistrement" peut dans ce cas avoir les valeurs <tt>ALLOW_NEW_SOURCES</tt> ou <tt>BLOCK_OLD_SOURCES</tt>.
| + | |
| − | ** <tt>LDAux</tt> contient la longueur du champ données supplémentaires
| + | |
| − | * <tt>adresse multicast</tt>
| + | |
| − | * <tt>nombre de sources</tt>
| + | |
| − | * <tt>adresse source [i]</tt>, vecteur contenant la liste des sources qui doivent être désormais autorisées ou bloquées | + | |
| − | * <tt>données supplémentaires</tt>, si elles sont présentes, peuvent contenir des informations supplémentaires concernant l'enregistrement d'adresse multicast en question.
| + | |
| − | | + | |
| − | Les rapports d'abonnement sont envoyés par les hôtes à l'adresse "tous les routeurs MLDv2" (<tt>ff02::16</tt>). Ainsi les récepteurs ne reçoivent pas les rapports des autres, chacun étant obligé d'envoyer son propre rapport. Le mécanisme d'économie d'émission des rapports du protocole MLDv1 n'est donc plus utilisé. Le risque de surcharge du routeur à cause du trop grand nombre de rapports reçus est toutefois évité en fixant des temporisateurs avec des valeurs différentes pour chaque rapport.
| + | |
| − | | + | |
| − | =====Fonctionnement de MLDv2=====
| + | |
| − | | + | |
| − | Comme dans le cas du MLDv1, s'il existe plusieurs routeurs multicast sur le même lien local, un seul routeur recenseur va être désigné à l'aide d'un mécanisme spécifique. Le recenseur envoie régulièrement des messages de recensement général auxquels les récepteurs répondent avec des rapports d'abonnement contenant des enregistrements d'état actuel.
| + | |
| − | | + | |
| − | Chaque hôte, ainsi que chaque routeur, gardent un état contenant le mode de filtrage et une liste des sources pour chaque adresse multicast. Dans le cas d'un hôte ce sont les adresses multicast sur lesquelles il écoute. Dans le cas d'un routeur ce sont les adresses multicast que ses récepteurs écoutent. Une application sur une machine hôte demande la modification du mode de filtrage ou de la liste des sources pour une adresse multicast précise à travers d'un appel <tt>EcouteIPv6Multicast</tt>. L'hôte inclut par conséquent ces modifications dans un rapport d'abonnement non-sollicité. Ce rapport contient des enregistrements de changement de mode de filtrage ou de la liste des sources, en conformité avec les changements qui ont eu lieu dans l'état interne de l'hôte.
| + | |
| − | | + | |
| − | Au moment de la réception des changements communiqués, le routeur met à jour son état pour l'adresse multicast concernée. Si, suite à ces changements, il constate qu'une certaine source ne doit plus être acceptée, le routeur envoie un message de recensement spécifique pour cette source, afin de vérifier l'existence d'éventuels récepteurs qui souhaitent toujours l'écouter. Un temporisateur est déclenché, et s'il expire sans que le routeur ait reçu un rapport d'abonnement concernant la source, celle-ci est éliminée de l'état local du routeur. Si le routeur détecte que plus aucune source n'est sollicitée pour une certaine adresse, il envoie un message de recensement spécifique pour cette adresse. Si des rapports d'abonnement concernant l'adresse en question ne sont pas reçus en temps dû, l'adresse est effacée de l'état du routeur.
| + | |
| − | | + | |
| − | {{suivi| Exemples de fonctionnement de MLDv1 | Exemples de fonctionnement de MLDv1 | Exemples de fonctionnement de MLDv2 | Exemples de fonctionnement de MLDv2}}
| + | |
| − | | + | |
| − | | + | |
| − | ==== Exemples de fonctionnement de MLDv2 (page à reprendre avec les exemples ====
| + | |
| − | | + | |
| − | = Sécurité =
| + | |
| − | = [[MobilitéBis|Mobilité dans IPv6]] (Thierry Ernst) =
| + | |
| − | | + | |
| − | = Intégration d'IPv6 et des applications (Bruno Stévant) =
| + | |
| − | = [[Programmation d'applications bis|Programmation d'applications]] (Etienne Dublé) =
| + | |
| − | | + | |
| − | = Supervision (Jean-Jacques Broussat) =
| + | |
| − | = Historique de la standardisation d’IPv6 =
| + | |
| − | = Bases whois=
| + | |
| − | = Bibliographie =
| + | |
Conserver la description des protocoles dans une première partie (éventuellement à mettre à jour -OSPF)
Réutiliser le chapitre "configuration des routeurs" dans un nouveau chapitre qui distinguerait
- une seconde partie, destinée à leurs clients (réseaux campus, entreprises, ...)
Discuter quelle fraction de la supervision fait partie de cette section (AS PATH tree, MIB BGP, ...)
