Livre IPv6 - User contributions [en]

Exemples de configuration dans un routeur Cisco

2010-01-04T10:28:39Z

Mcoic: /* Contexte */

=Déploiement multicast IPv6 sur un routeur Cisco (A COMPLETER)=

== Contexte ==

Avec un IOS avancé (de type ipadvance ou ipadventreprise), il est possible d’implémenter une plate-forme de multicast IPv6 avec des routeurs Cisco. Concrètement ceci se résume à dire au routeur de gérer le multicast et à configurer des points de rendez-vous.

Cette page présente également une solution pour permettre la diffusion de flux multicast à travers un cœur MPLS en étant compatible avec la technologie 6PE. La principale difficulté de réalisation vient du fait que les PE encapsulent les données dans un label suivant l’adresse de destination du paquet. Il s'agit donc de construire une table de routage multicast annexe.
L’inconvénient de la solution est qu’il est nécessaire d’assigner des adresses IPv6 au routeur P pour monter un réseau parallèle au MPLS.

Cette solution utilise des routeurs Cisco avec un IOS 15.0. Il faut au préalable installer un cœur MPLS avec la fonction 6PE avant de se lancer dans la configuration (voir page [[ La_technique_6PE | 6PE ]]).

== Exemple de configuration multicast IPv6 dans un routeur Cisco ==

Voici les commandes à entrer en mode "configuration globale" :

ipv6 multicast-routing
ipv6 pim rp-address 2001:4C18:20::1
ipv6 pim register-source Loopback6
ipv6 pim spt-threshold infinity

Lorsque la commande ipv6 multicast-routing est rentrée, le routeur va automatiquement configurer le protocole PIM sur chacune de ses interfaces. Il est possible de changer les valeurs par défaut avec les options "ipv6 pim". Par exemple l'option "ipv6 pim register-source" permet de choisir l'adresse source utilisée par le routeur pour envoyer les messages PIM. Pour que les messages puissent transiter entre les routeurs, il faut donc que les adresses loopback des routeurs transitant le multicast soient dans les tables de routage. L'avantage des interfaces Loopback est qu'elles sont toujours dans l'état "UP", même en cas de débranchement de câbles imprévu.

La configuration de RP est nécessaire même si on utilise la technologie Embedded-RP car le routeur va monter les interfaces tunnels virtuels nécessaire pour le transit des paquets multicast. Il est conseillé d'utiliser les interfaces Loopback pour jouer le rôle de RP pour les mêmes raisons évoquées dans le paragraphe précédent. Les commandes ci-dessus suffisent pour le cas où le routeur doit jouer le rôle de RP.

Si on utilise les adresses multicast temporaires, on peut utiliser des access-list qui vont choisir le point de rendez-vous suivant l'adresse du flux.

Voici un exemple d'utilisation d'access-list :
ipv6 pim rp-address 2001:4C18:20::1 list1
ipv6 pim rp-address 2001:4C18:20::2 list2
ipv6 access-list list1
sequence 20 permit ipv6 any FF1E:40:2001:4C18:20:1::/96
ipv6 access-list list2
sequence 20 permit ipv6 any FF1E:40:2001:4C18:20:2::/96

Pour tester les configurations, on peut voir les messages PIM échangés entre les routeurs grâce à la commande "debug ipv6 pim". Pour quitter ce mode, il suffit de rentrer "no debug ipv6 pim".
Pour voir la table de routage multicast, il faut entrer la commande "show ipv6 mroute". Par exemple :

R38-PE-2#sh ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State
(*, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:04:14/00:03:13, RP 2001:4C18:20::2, flags: SC
Incoming interface: Tunnel1
RPF nbr: 2001:4C18:20::2
Immediate Outgoing interface list:
GigabitEthernet0/0, Forward, 00:04:14/never
GigabitEthernet0/1, Forward, 00:04:12/00:03:13
(2001:4C18:20:1:221:86FF:FE52:D383, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 01:06:40/00:03:29, flags: SJ
Incoming interface: Loopback6
RPF nbr: FE80::213:C3FF:FE7D:2110
Inherited Outgoing interface list:
GigabitEthernet0/0, Forward, 00:04:14/never
GigabitEthernet0/1, Forward, 00:04:12/00:03:13
(2001:4C18:20:2:21A:4BFF:FE63:3894, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:04:11/00:02:48, flags: SFJT
Incoming interface: GigabitEthernet0/0
RPF nbr: 2001:4C18:20:2:21A:4BFF:FE63:3894
Inherited Outgoing interface list:
GigabitEthernet0/1, Forward, 00:04:12/00:03:13
(2001:4C18:20:3:250:56FF:FEA5:4262, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:03:39/00:03:29, flags: SJ
Incoming interface: Loopback6
RPF nbr: FE80::213:C3FF:FE7D:2110
Inherited Outgoing interface list:
GigabitEthernet0/0, Forward, 00:04:14/never
GigabitEthernet0/1, Forward, 00:04:12/00:03:13

== Exemple de configuration multicast IPv6 dans un cœur MPLS ==

Dans un cœur MPLS, il n'est pas nécessaire d'assigner des adresses IPv6 sur les interfaces entre les routeurs PE et P. Or, si l'interface n'a pas d'adresse IPv6, le routeur ne va pas implémenter le protocole PIM sur elle, ce qui rend l'échange de messages PIM impossible même si on utilise les adresses Loopbacks.

C'est pourquoi dans notre cas, il faut monter un réseau parallèle dédié au multicast IPv6. Tous les échanges entre les adresses Unicast seront encapsulés dans des labels et transiteront par le cœur MPLS alors que les flux multicast transiteront directement. Pour cela Il faut assigner des adresses IPv6 à chaque interconnexion entre les PEs et les routeurs P et à chaque Loopback des routeurs. Ensuite il est nécessaire d’implémenter un protocole de routage dynamique pour construire la table de routage que les messages PIM utiliseront lors de la construction de l’arbre multicast.

Ici, le protocole OSPF a été choisi pour sa simplicité d'implémentation. Voici la configuration retenue dans notre exemple :

ipv6 router ospf 1
router-id 192.168.127.1
log-adjacency-changes detail
!

Pour le "router-id", il suffit de mettre l'adresse IPv4 de la Loopback. Ensuite il faut appliquer le protocole sur chaque interface où on veut que l'adresse soit partagée :

interface GigabitEthernet0/1
description Vers_le_routeur_P
ip address 192.168.11.2 255.255.255.0
ip router isis
duplex auto
speed auto
media-type rj45
ipv6 address 2001:4C18:2C:1::2/64
ipv6 enable
ipv6 ospf 1 area 0
mpls label protocol ldp
mpls ip
!
!

On voit bien dans cette configuration le parallélisme entre le cœur MPLS et le réseau multicast. Suivant la destination et le type du paquet, l'interface va encapsuler ou non le paquet.
Le réseau Multicast doit donc ressembler à ça :

[[Image:ArchiOSPFoverMPLS.jpg|thumb|center|600px|Figure 11-1 ''Configuration OSPF'']]

Et pour le coeur MPLS on a :
[[Image:ArchiMPLS.jpg|thumb|center|600px|Figure 11-1 ''Architecture cœur MPLS'']]

== Défauts et difficultés éventuelles de mise en œuvre ==

L'architecture retenue ressemble plus à une solution temporaire que définitive avec ces 2 réseaux en parallèle. Elle présente en effet plusieurs inconvénients. D'une part, l'intérêt d'un cœur MPLS diminue puisque l'IPv6 doit être implémenté dans le routeur P. Le rôle principal du MPLS est de pouvoir transiter des paquets avec n'importe quel protocole. D'autre part, 2 réseaux doivent être gérés en même temps, ce qui pose des problèmes de mise en œuvre puisqu'un problème sur un réseau peut se répercuter sur l'autre.

== Autres solutions à venir ==
L’utilisation de 6vPE peut être une solution définitive. Le principe de 6vPE repose sur l’établissement de vrf (voir [[Réseaux_privés_virtuels_IPv6_sur_MPLS | 6vPE]]). Il n’est pas possible aujourd’hui de configurer des RP dans une vrf. Du coup comme les clients viennent des interfaces incluses dans une vrf, le RP ne voit pas la demande d’inscription du client. Par contre, pour l’IPv4, les routeurs cisco offrent déjà des fonctionnalités bien plus compatibles avec le multicast puisqu’on peut configurer un RP dans une vrf. Il faut donc attendre une mise-à-jour de Cisco pour peut-être offrir une solution d’architecture où le routeur P n’a pas besoin d’implémenter d’interface IPv6.

Exemples de configuration dans un routeur Cisco

2010-01-04T10:20:57Z

Mcoic: /* Déploiement multicast IPv6 sur un routeur Cisco (A COMPLETER) */

=Déploiement multicast IPv6 sur un routeur Cisco (A COMPLETER)=

== Contexte ==

Avec un IOS avancé (de type ipadvance ou ipadventreprise), il est possible d’implémenter une plate-forme de multicast IPv6 avec des routeurs Cisco. Concrètement ceci se résume à dire au routeur de gérer le multicast et à configurer des points de rendez-vous.

Cette page présente également une solution possible pour permettre la diffusion de flux multicast à travers un cœur MPLS en étant compatible avec la technologie 6PE. La principale difficulté de réalisation vient du fait que les PE encapsulent les données dans un label suivant l’adresse de destination du paquet. Il s'agit donc de construire une table de routage multicast annexe.
L’inconvénient de la solution est qu’il est nécessaire d’assigner des adresses IPv6 au routeur P pour monter un réseau parallèle au MPLS.

Cette solution utilise des routeurs Cisco avec un IOS 15.0. Il faut au préalable installer un cœur MPLS avec la fonction 6PE avant de se lancer dans la configuration (voir page [[ La_technique_6PE | 6PE ]]).

== Exemple de configuration multicast IPv6 dans un routeur Cisco ==

Voici les commandes à entrer en mode "configuration globale" :

ipv6 multicast-routing
ipv6 pim rp-address 2001:4C18:20::1
ipv6 pim register-source Loopback6
ipv6 pim spt-threshold infinity

Lorsque la commande ipv6 multicast-routing est rentrée, le routeur va automatiquement configurer le protocole PIM sur chacune de ses interfaces. Il est possible de changer les valeurs par défaut avec les options "ipv6 pim". Par exemple l'option "ipv6 pim register-source" permet de choisir l'adresse source utilisée par le routeur pour envoyer les messages PIM. Pour que les messages puissent transiter entre les routeurs, il faut donc que les adresses loopback des routeurs transitant le multicast soient dans les tables de routage. L'avantage des interfaces Loopback est qu'elles sont toujours dans l'état "UP", même en cas de débranchement de câbles imprévu.

La configuration de RP est nécessaire même si on utilise la technologie Embedded-RP car le routeur va monter les interfaces tunnels virtuels nécessaire pour le transit des paquets multicast. Il est conseillé d'utiliser les interfaces Loopback pour jouer le rôle de RP pour les mêmes raisons évoquées dans le paragraphe précédent. Les commandes ci-dessus suffisent pour le cas où le routeur doit jouer le rôle de RP.

Si on utilise les adresses multicast temporaires, on peut utiliser des access-list qui vont choisir le point de rendez-vous suivant l'adresse du flux.

Voici un exemple d'utilisation d'access-list :
ipv6 pim rp-address 2001:4C18:20::1 list1
ipv6 pim rp-address 2001:4C18:20::2 list2
ipv6 access-list list1
sequence 20 permit ipv6 any FF1E:40:2001:4C18:20:1::/96
ipv6 access-list list2
sequence 20 permit ipv6 any FF1E:40:2001:4C18:20:2::/96

Pour tester les configurations, on peut voir les messages PIM échangés entre les routeurs grâce à la commande "debug ipv6 pim". Pour quitter ce mode, il suffit de rentrer "no debug ipv6 pim".
Pour voir la table de routage multicast, il faut entrer la commande "show ipv6 mroute". Par exemple :

R38-PE-2#sh ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State
(*, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:04:14/00:03:13, RP 2001:4C18:20::2, flags: SC
Incoming interface: Tunnel1
RPF nbr: 2001:4C18:20::2
Immediate Outgoing interface list:
GigabitEthernet0/0, Forward, 00:04:14/never
GigabitEthernet0/1, Forward, 00:04:12/00:03:13
(2001:4C18:20:1:221:86FF:FE52:D383, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 01:06:40/00:03:29, flags: SJ
Incoming interface: Loopback6
RPF nbr: FE80::213:C3FF:FE7D:2110
Inherited Outgoing interface list:
GigabitEthernet0/0, Forward, 00:04:14/never
GigabitEthernet0/1, Forward, 00:04:12/00:03:13
(2001:4C18:20:2:21A:4BFF:FE63:3894, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:04:11/00:02:48, flags: SFJT
Incoming interface: GigabitEthernet0/0
RPF nbr: 2001:4C18:20:2:21A:4BFF:FE63:3894
Inherited Outgoing interface list:
GigabitEthernet0/1, Forward, 00:04:12/00:03:13
(2001:4C18:20:3:250:56FF:FEA5:4262, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:03:39/00:03:29, flags: SJ
Incoming interface: Loopback6
RPF nbr: FE80::213:C3FF:FE7D:2110
Inherited Outgoing interface list:
GigabitEthernet0/0, Forward, 00:04:14/never
GigabitEthernet0/1, Forward, 00:04:12/00:03:13

== Exemple de configuration multicast IPv6 dans un cœur MPLS ==

Dans un cœur MPLS, il n'est pas nécessaire d'assigner des adresses IPv6 sur les interfaces entre les routeurs PE et P. Or, si l'interface n'a pas d'adresse IPv6, le routeur ne va pas implémenter le protocole PIM sur elle, ce qui rend l'échange de messages PIM impossible même si on utilise les adresses Loopbacks.

C'est pourquoi dans notre cas, il faut monter un réseau parallèle dédié au multicast IPv6. Tous les échanges entre les adresses Unicast seront encapsulés dans des labels et transiteront par le cœur MPLS alors que les flux multicast transiteront directement. Pour cela Il faut assigner des adresses IPv6 à chaque interconnexion entre les PEs et les routeurs P et à chaque Loopback des routeurs. Ensuite il est nécessaire d’implémenter un protocole de routage dynamique pour construire la table de routage que les messages PIM utiliseront lors de la construction de l’arbre multicast.

Ici, le protocole OSPF a été choisi pour sa simplicité d'implémentation. Voici la configuration retenue dans notre exemple :

ipv6 router ospf 1
router-id 192.168.127.1
log-adjacency-changes detail
!

Pour le "router-id", il suffit de mettre l'adresse IPv4 de la Loopback. Ensuite il faut appliquer le protocole sur chaque interface où on veut que l'adresse soit partagée :

interface GigabitEthernet0/1
description Vers_le_routeur_P
ip address 192.168.11.2 255.255.255.0
ip router isis
duplex auto
speed auto
media-type rj45
ipv6 address 2001:4C18:2C:1::2/64
ipv6 enable
ipv6 ospf 1 area 0
mpls label protocol ldp
mpls ip
!
!

On voit bien dans cette configuration le parallélisme entre le cœur MPLS et le réseau multicast. Suivant la destination et le type du paquet, l'interface va encapsuler ou non le paquet.
Le réseau Multicast doit donc ressembler à ça :

[[Image:ArchiOSPFoverMPLS.jpg|thumb|center|600px|Figure 11-1 ''Configuration OSPF'']]

Et pour le coeur MPLS on a :
[[Image:ArchiMPLS.jpg|thumb|center|600px|Figure 11-1 ''Architecture cœur MPLS'']]

== Défauts et difficultés éventuelles de mise en œuvre ==

L'architecture retenue ressemble plus à une solution temporaire que définitive avec ces 2 réseaux en parallèle. Elle présente en effet plusieurs inconvénients. D'une part, l'intérêt d'un cœur MPLS diminue puisque l'IPv6 doit être implémenté dans le routeur P. Le rôle principal du MPLS est de pouvoir transiter des paquets avec n'importe quel protocole. D'autre part, 2 réseaux doivent être gérés en même temps, ce qui pose des problèmes de mise en œuvre puisqu'un problème sur un réseau peut se répercuter sur l'autre.

== Autres solutions à venir ==
L’utilisation de 6vPE peut être une solution définitive. Le principe de 6vPE repose sur l’établissement de vrf (voir [[Réseaux_privés_virtuels_IPv6_sur_MPLS | 6vPE]]). Il n’est pas possible aujourd’hui de configurer des RP dans une vrf. Du coup comme les clients viennent des interfaces incluses dans une vrf, le RP ne voit pas la demande d’inscription du client. Par contre, pour l’IPv4, les routeurs cisco offrent déjà des fonctionnalités bien plus compatibles avec le multicast puisqu’on peut configurer un RP dans une vrf. Il faut donc attendre une mise-à-jour de Cisco pour peut-être offrir une solution d’architecture où le routeur P n’a pas besoin d’implémenter d’interface IPv6.

Exemples de configuration dans un routeur Cisco

2010-01-04T09:18:06Z

Mcoic: /* Déploiement multicast IPv6 sur un routeur Cisco (A COMPLETER) */

=Déploiement multicast IPv6 sur un routeur Cisco (A COMPLETER)=

== Contexte ==

Avec un IOS avancé (de type ipadvance ou ipadventreprise), il est possible d’implémenter une plate-forme de multicast IPv6 avec des routeurs Cisco. Concrètement ceci se résume à dire au routeur de gérer le multicast et à configurer des points de rendez-vous.

Cette page présente également une solution possible pour permettre la diffusion de flux multicast à travers un cœur MPLS en étant compatible avec la technologie 6PE. La principale difficulté de réalisation vient du fait que les PE encapsulent les données dans un label suivant l’adresse de destination du paquet. Il s'agit donc de construire une table de routage multicast annexe.
L’inconvénient de la solution est qu’il est nécessaire d’assigner des adresses IPv6 au routeur P pour monter un réseau parallèle au MPLS.

Cette solution utilise des routeurs Cisco avec un IOS 15.0. Il faut au préalable installer un cœur MPLS avec la fonction 6PE avant de se lancer dans la configuration (voir page [[ La_technique_6PE | 6PE ]]).

== Exemple de configuration multicast IPv6 dans un routeur Cisco ==

Voici les commandes à entrer en mode "configuration globale" :

ipv6 multicast-routing
ipv6 pim rp-address 2001:4C18:20::1
ipv6 pim register-source Loopback6
ipv6 pim spt-threshold infinity

Lorsque la commande ipv6 multicast-routing est rentrée, le routeur va automatiquement configurer le protocole PIM sur chacune de ses interfaces. Il est possible de changer les valeurs par défaut avec les options "ipv6 pim". Par exemple l'option "ipv6 pim register-source" permet de choisir l'adresse source utilisée par le routeur pour envoyer les messages PIM. Pour que les messages puissent transiter entre les routeurs, il faut donc que les adresses loopback des routeurs transitant le multicast soient dans les tables de routage. L'avantage des interfaces Loopback est qu'elles sont toujours dans l'état "UP", même en cas de débranchement de câbles imprévu.

La configuration de RP est nécessaire même si on utilise la technologie Embedded-RP car le routeur va monter les interfaces tunnels virtuels nécessaire pour le transit des paquets multicast. Il est conseillé d'utiliser les interfaces Loopback pour jouer le rôle de RP pour les mêmes raisons évoquées dans le paragraphe précédent. Les commandes ci-dessus suffisent pour le cas où le routeur doit jouer le rôle de RP.

Si on utilise les adresses multicast temporaires, on peut utiliser des access-list qui vont choisir le point de rendez-vous suivant l'adresse du flux.

Voici un exemple d'utilisation d'access-list :
ipv6 pim rp-address 2001:4C18:20::1 list1
ipv6 pim rp-address 2001:4C18:20::2 list2
ipv6 access-list list1
sequence 20 permit ipv6 any FF1E:40:2001:4C18:20:1::/96
ipv6 access-list list2
sequence 20 permit ipv6 any FF1E:40:2001:4C18:20:2::/96

Pour tester les configurations, on peut voir les messages PIM échangés entre les routeurs grâce à la commande "debug ipv6 pim". Pour quitter ce mode, il suffit de rentrer "no debug ipv6 pim".
Pour voir la table de routage multicast, il faut entrer la commande "show ipv6 mroute". Par exemple :

R38-PE-2#sh ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State
(*, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:04:14/00:03:13, RP 2001:4C18:20::2, flags: SC
Incoming interface: Tunnel1
RPF nbr: 2001:4C18:20::2
Immediate Outgoing interface list:
GigabitEthernet0/0, Forward, 00:04:14/never
GigabitEthernet0/1, Forward, 00:04:12/00:03:13
(2001:4C18:20:1:221:86FF:FE52:D383, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 01:06:40/00:03:29, flags: SJ
Incoming interface: Loopback6
RPF nbr: FE80::213:C3FF:FE7D:2110
Inherited Outgoing interface list:
GigabitEthernet0/0, Forward, 00:04:14/never
GigabitEthernet0/1, Forward, 00:04:12/00:03:13
(2001:4C18:20:2:21A:4BFF:FE63:3894, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:04:11/00:02:48, flags: SFJT
Incoming interface: GigabitEthernet0/0
RPF nbr: 2001:4C18:20:2:21A:4BFF:FE63:3894
Inherited Outgoing interface list:
GigabitEthernet0/1, Forward, 00:04:12/00:03:13
(2001:4C18:20:3:250:56FF:FEA5:4262, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:03:39/00:03:29, flags: SJ
Incoming interface: Loopback6
RPF nbr: FE80::213:C3FF:FE7D:2110
Inherited Outgoing interface list:
GigabitEthernet0/0, Forward, 00:04:14/never
GigabitEthernet0/1, Forward, 00:04:12/00:03:13

== Exemple de configuration multicast IPv6 dans un cœur MPLS ==

Il faut assigner des adresses IPv6 à chaque interconnexion entre les PEs et les routeurs P et à chaque Loopback des routeurs. En effet, si l'interface n'a pas d'adresse IPv6, le routeur ne va pas implémenter le protocole PIM sur elle. Ensuite il est nécessaire d’implémenter un protocole de routage dynamique pour construire la table de routage que les messages PIM utiliseront lors de la construction de l’arbre multicast.

Ici, le protocole OSPF a été choisi pour sa simplicité d'implémentation. Voici les commandes qu'il faut entrer :

ipv6 router ospf 1
router-id 192.168.127.1
log-adjacency-changes detail
!

Pour le "router-id", il suffit de mettre l'adresse IPv4 de la Loopback. Ensuite il faut appliquer le protocole sur chaque interface où on veut que l'adresse soit partagée :

interface GigabitEthernet0/1
descrition Vers_le_routeur_P
ip address 192.168.11.2 255.255.255.0
ip router isis
duplex auto
speed auto
media-type rj45
ipv6 address 2001:4C18:2C:1::2/64
ipv6 enable
ipv6 ospf 1 area 0
mpls label protocol ldp
mpls ip
!
!

Le but étant d'obtenir ce type d'architecture :

[[Image:ArchiOSPFoverMPLS.jpg|thumb|center|600px|Figure 11-1 ''Configuration OSPF'']]

Et le schéma entier de l’architecture mise en place donne ceci :
[[Image:ArchiMPLS.jpg|thumb|center|600px|Figure 11-1 ''Architecture cœur MPLS'']]

== Autres solutions ==
L’utilisation de 6vPE peut être une solution définitive. Le principe de 6vPE repose sur l’établissement de vrf (voir [[Réseaux_privés_virtuels_IPv6_sur_MPLS | 6vPE]]). Il n’est pas possible aujourd’hui de configurer des RP dans une vrf. Du coup comme les clients viennent des interfaces incluses dans une vrf, le RP ne voit pas la demande d’inscription du client. Par contre, pour l’IPv4, les routeurs cisco offrent déjà des fonctionnalités bien plus compatibles avec le multicast puisqu’on peut configurer un RP dans une vrf. Il faut donc attendre une mise-à-jour de Cisco pour peut-être offrir une solution d’architecture où le routeur P n’a pas besoin d’implémenter d’interface IPv6.

Exemples de configuration dans un routeur Cisco

2009-12-23T09:56:26Z

Mcoic: /* Exemple de configuration multicast IPv6 dans un routeur Cisco */

=Déploiement multicast IPv6 sur un routeur Cisco (A COMPLETER)=

== Contexte ==

Avec un IOS avancé (de type ipadvance ou ipadventreprise), il est possible d’implémenter une plate-forme de multicast IPv6 avec des routeurs Cisco. Concrètement ceci se résume à dire au routeur de gérer le multicast et à configurer des points de rendez-vous.

Cette page présente également une solution possible pour permettre la diffusion de flux multicast à travers un cœur MPLS en étant compatible avec la technologie 6PE. La principale difficulté de réalisation vient du fait que les PE encapsulent les données dans un label suivant l’adresse de destination du paquet. Il s'agit donc de construire une table de routage multicast annexe.
L’inconvénient de la solution est qu’il est nécessaire d’assigner des adresses IPv6 au routeur P pour monter un réseau parallèle au MPLS.

Cette solution utilise des routeurs Cisco avec un IOS 15.0. Il faut au préalable installer un cœur MPLS avec la fonction 6PE avant de lancer la configuration (voir page [[ La_technique_6PE | 6PE ]]).

== Exemple de configuration multicast IPv6 dans un routeur Cisco ==

Voici les commandes à entrer en mode "configuration globale" :

ipv6 multicast-routing
ipv6 pim rp-address 2001:4C18:20::1
ipv6 pim register-source Loopback6
ipv6 pim spt-threshold infinity

Lorsque la commande ipv6 multicast-routing est rentrée, le routeur va automatiquement configurer le protocole PIM sur chacune de ses interfaces. Il est possible de changer les valeurs par défaut avec les options "ipv6 pim".

La configuration de RP est nécessaire même si on utilise la technologie Embedded-RP car le routeur va monter les interfaces tunnels virtuels nécessaire pour le transit des paquets multicast. Il est conseillé de prendre les adresses des Loopback pour les points de rendez-vous car ces interfaces sont toujours "UP". Les commandes ci-dessus suffisent pour le cas où le routeur doit jouer le rôle de RP.

Si on utilise les adresses multicast temporaires, on peut utiliser des access-list qui vont choisir le point de rendez-vous suivant l'adresse du flux.

Voici un exemple d'utilisation d'access-list :
ipv6 pim rp-address 2001:4C18:20::1 list1
ipv6 pim rp-address 2001:4C18:20::2 list2
ipv6 access-list list1
sequence 20 permit ipv6 any FF1E:40:2001:4C18:20:1::/96
ipv6 access-list list2
sequence 20 permit ipv6 any FF1E:40:2001:4C18:20:2::/96

Pour tester les configurations, on peut voir les messages PIM échangés entre les routeurs grâce à la commande "debug ipv6 pim". Pour quitter ce mode, il suffit de rentrer "no debug ipv6 pim".
Pour voir la table de routage multicast, il faut entrer la commande "show ipv6 mroute". Par exemple :

R38-PE-2#sh ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State
(*, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:04:14/00:03:13, RP 2001:4C18:20::2, flags: SC
Incoming interface: Tunnel1
RPF nbr: 2001:4C18:20::2
Immediate Outgoing interface list:
GigabitEthernet0/0, Forward, 00:04:14/never
GigabitEthernet0/1, Forward, 00:04:12/00:03:13
(2001:4C18:20:1:221:86FF:FE52:D383, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 01:06:40/00:03:29, flags: SJ
Incoming interface: Loopback6
RPF nbr: FE80::213:C3FF:FE7D:2110
Inherited Outgoing interface list:
GigabitEthernet0/0, Forward, 00:04:14/never
GigabitEthernet0/1, Forward, 00:04:12/00:03:13
(2001:4C18:20:2:21A:4BFF:FE63:3894, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:04:11/00:02:48, flags: SFJT
Incoming interface: GigabitEthernet0/0
RPF nbr: 2001:4C18:20:2:21A:4BFF:FE63:3894
Inherited Outgoing interface list:
GigabitEthernet0/1, Forward, 00:04:12/00:03:13
(2001:4C18:20:3:250:56FF:FEA5:4262, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:03:39/00:03:29, flags: SJ
Incoming interface: Loopback6
RPF nbr: FE80::213:C3FF:FE7D:2110
Inherited Outgoing interface list:
GigabitEthernet0/0, Forward, 00:04:14/never
GigabitEthernet0/1, Forward, 00:04:12/00:03:13

== Exemple de configuration multicast IPv6 dans un cœur MPLS ==

Il faut assigner des adresses IPv6 à chaque interconnexion entre les PEs et les routeurs P et à chaque Loopback des routeurs. En effet, si l'interface n'a pas d'adresse IPv6, le routeur ne va pas implémenter le protocole PIM sur elle. Ensuite il est nécessaire d’implémenter un protocole de routage dynamique pour construire la table de routage que les messages PIM utiliseront lors de la construction de l’arbre multicast.

Ici, le protocole OSPF a été choisi pour sa simplicité d'implémentation. Voici les commandes qu'il faut entrer :

ipv6 router ospf 1
router-id 192.168.127.1
log-adjacency-changes detail
!

Pour le "router-id", il suffit de mettre l'adresse IPv4 de la Loopback. Ensuite il faut appliquer le protocole sur chaque interface où on veut que l'adresse soit partagée :

interface GigabitEthernet0/1
descrition Vers_le_routeur_P
ip address 192.168.11.2 255.255.255.0
ip router isis
duplex auto
speed auto
media-type rj45
ipv6 address 2001:4C18:2C:1::2/64
ipv6 enable
ipv6 ospf 1 area 0
mpls label protocol ldp
mpls ip
!
!

Le but étant d'obtenir ce type d'architecture :

[[Image:ArchiOSPFoverMPLS.jpg|thumb|center|600px|Figure 11-1 ''Configuration OSPF'']]

Et le schéma entier de l’architecture mise en place donne ceci :
[[Image:ArchiMPLS.jpg|thumb|center|600px|Figure 11-1 ''Architecture cœur MPLS'']]

== Autres solutions ==
L’utilisation de 6vPE peut être une solution définitive. Le principe de 6vPE repose sur l’établissement de vrf (voir [[Réseaux_privés_virtuels_IPv6_sur_MPLS | 6vPE]]). Il n’est pas possible aujourd’hui de configurer des RP dans une vrf. Du coup comme les clients viennent des interfaces incluses dans une vrf, le RP ne voit pas la demande d’inscription du client. Par contre, pour l’IPv4, les routeurs cisco offrent déjà des fonctionnalités bien plus compatibles avec le multicast puisqu’on peut configurer un RP dans une vrf. Il faut donc attendre une mise-à-jour de Cisco pour peut-être offrir une solution d’architecture où le routeur P n’a pas besoin d’implémenter d’interface IPv6.

Exemples de configuration dans un routeur Cisco

2009-12-22T16:02:31Z

Mcoic: /* Exemple de configuration multicast IPv6 dans un cœur MPLS */

=Déploiement multicast IPv6 sur un routeur Cisco (A COMPLETER)=

== Contexte ==

Avec un IOS avancé (de type ipadvance ou ipadventreprise), il est possible d’implémenter une plate-forme de multicast IPv6 avec des routeurs Cisco. Concrètement ceci se résume à dire au routeur de gérer le multicast et à configurer des points de rendez-vous.

Cette page présente également une solution possible pour permettre la diffusion de flux multicast à travers un cœur MPLS en étant compatible avec la technologie 6PE. La principale difficulté de réalisation vient du fait que les PE encapsulent les données dans un label suivant l’adresse de destination du paquet. Il s'agit donc de construire une table de routage multicast annexe.
L’inconvénient de la solution est qu’il est nécessaire d’assigner des adresses IPv6 au routeur P pour monter un réseau parallèle au MPLS.

Cette solution utilise des routeurs Cisco avec un IOS 15.0. Il faut au préalable installer un cœur MPLS avec la fonction 6PE avant de lancer la configuration (voir page [[ La_technique_6PE | 6PE ]]).

== Exemple de configuration multicast IPv6 dans un routeur Cisco ==

Voici les commandes à entrer en mode "configuration globale" :

ipv6 multicast-routing
ipv6 pim rp-address 2001:4C18:20::1
ipv6 pim register-source Loopback6
ipv6 pim spt-threshold infinity

Lorsque la commande ipv6 multicast-routing est rentrée, le routeur va automatiquement configurer le protocole PIM sur chacune de ses interfaces. Il est possible de changer les valeurs par défaut avec les options "ipv6 pim".

La configuration de RP est nécessaire même si on utilise la technologie Embedded-RP car le routeur va monter les interfaces tunnels virtuels nécessaire pour le transit des paquets multicast. Il est conseillé de prendre les adresses des Loopback pour les points de rendez-vous car ces interfaces sont toujours "UP". Les commandes ci-dessus suffisent pour le cas où le routeur doit jouer le rôle de RP.

Si on utilise les adresses multicast temporaires, on peut utiliser des access-list qui vont choisir le point de rendez-vous suivant l'adresse du flux.

Voici un exemple d'utilisation d'access-list :
ipv6 pim rp-address 2001:4C18:20::1 list1
ipv6 pim rp-address 2001:4C18:20::2 list2
ipv6 access-list list1
sequence 20 permit ipv6 any FF1E:40:2001:4C18:20:1::/96
ipv6 access-list list2
sequence 20 permit ipv6 any FF1E:40:2001:4C18:20:2::/96

Pour tester les configurations, on peut voir les messages PIM échangés entre les routeurs grâce à la commande "debug ipv6 pim". Pour quitter ce mode, il suffit de rentrer "no debug ipv6 pim".
Pour voir la table de routage multicast, il faut entrer la commande "show ipv6 mroute". Par exemple :

R38-PE-2#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State
(*, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:00:58/00:02:35, RP 2001:4C18:20::2, flags: SC
Incoming interface: Tunnel1
RPF nbr: 2001:4C18:20::2
Immediate Outgoing interface list:
GigabitEthernet0/0, Forward, 00:00:58/never
GigabitEthernet0/1, Forward, 00:00:54/00:02:35
(2001:4C18:20:1:221:86FF:FE52:D383, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:00:51/00:03:29, flags: SJ
Incoming interface: Loopback6
RPF nbr: FE80::213:C3FF:FE7D:2110
Inherited Outgoing interface list:
GigabitEthernet0/0, Forward, 00:00:58/never
GigabitEthernet0/1, Forward, 00:00:54/00:02:35
(2001:4C18:20:2:21A:4BFF:FE63:3894, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:00:55/00:02:34, flags: SFJT
Incoming interface: GigabitEthernet0/0
RPF nbr: 2001:4C18:20:2:21A:4BFF:FE63:3894
Inherited Outgoing interface list:
GigabitEthernet0/1, Forward, 00:00:54/00:02:35

== Exemple de configuration multicast IPv6 dans un cœur MPLS ==

Il faut assigner des adresses IPv6 à chaque interconnexion entre les PEs et les routeurs P et à chaque Loopback des routeurs. En effet, si l'interface n'a pas d'adresse IPv6, le routeur ne va pas implémenter le protocole PIM sur elle. Ensuite il est nécessaire d’implémenter un protocole de routage dynamique pour construire la table de routage que les messages PIM utiliseront lors de la construction de l’arbre multicast.

Ici, le protocole OSPF a été choisi pour sa simplicité d'implémentation. Voici les commandes qu'il faut entrer :

ipv6 router ospf 1
router-id 192.168.127.1
log-adjacency-changes detail
!

Pour le "router-id", il suffit de mettre l'adresse IPv4 de la Loopback. Ensuite il faut appliquer le protocole sur chaque interface où on veut que l'adresse soit partagée :

interface GigabitEthernet0/1
descrition Vers_le_routeur_P
ip address 192.168.11.2 255.255.255.0
ip router isis
duplex auto
speed auto
media-type rj45
ipv6 address 2001:4C18:2C:1::2/64
ipv6 enable
ipv6 ospf 1 area 0
mpls label protocol ldp
mpls ip
!
!

Le but étant d'obtenir ce type d'architecture :

[[Image:ArchiOSPFoverMPLS.jpg|thumb|center|600px|Figure 11-1 ''Configuration OSPF'']]

Et le schéma entier de l’architecture mise en place donne ceci :
[[Image:ArchiMPLS.jpg|thumb|center|600px|Figure 11-1 ''Architecture cœur MPLS'']]

== Autres solutions ==
L’utilisation de 6vPE peut être une solution définitive. Le principe de 6vPE repose sur l’établissement de vrf (voir [[Réseaux_privés_virtuels_IPv6_sur_MPLS | 6vPE]]). Il n’est pas possible aujourd’hui de configurer des RP dans une vrf. Du coup comme les clients viennent des interfaces incluses dans une vrf, le RP ne voit pas la demande d’inscription du client. Par contre, pour l’IPv4, les routeurs cisco offrent déjà des fonctionnalités bien plus compatibles avec le multicast puisqu’on peut configurer un RP dans une vrf. Il faut donc attendre une mise-à-jour de Cisco pour peut-être offrir une solution d’architecture où le routeur P n’a pas besoin d’implémenter d’interface IPv6.

Exemples de configuration dans un routeur Cisco

2009-12-22T15:56:28Z

Mcoic: New page: =Déploiement multicast IPv6 sur un routeur Cisco (A COMPLETER)= == Contexte == Avec un IOS avancé (de type ipadvance ou ipadventreprise), il est possible d’implémenter une plate-for...

=Déploiement multicast IPv6 sur un routeur Cisco (A COMPLETER)=

== Contexte ==

Avec un IOS avancé (de type ipadvance ou ipadventreprise), il est possible d’implémenter une plate-forme de multicast IPv6 avec des routeurs Cisco. Concrètement ceci se résume à dire au routeur de gérer le multicast et à configurer des points de rendez-vous.

Cette page présente également une solution possible pour permettre la diffusion de flux multicast à travers un cœur MPLS en étant compatible avec la technologie 6PE. La principale difficulté de réalisation vient du fait que les PE encapsulent les données dans un label suivant l’adresse de destination du paquet. Il s'agit donc de construire une table de routage multicast annexe.
L’inconvénient de la solution est qu’il est nécessaire d’assigner des adresses IPv6 au routeur P pour monter un réseau parallèle au MPLS.

Cette solution utilise des routeurs Cisco avec un IOS 15.0. Il faut au préalable installer un cœur MPLS avec la fonction 6PE avant de lancer la configuration (voir page [[ La_technique_6PE | 6PE ]]).

== Exemple de configuration multicast IPv6 dans un routeur Cisco ==

Voici les commandes à entrer en mode "configuration globale" :

ipv6 multicast-routing
ipv6 pim rp-address 2001:4C18:20::1
ipv6 pim register-source Loopback6
ipv6 pim spt-threshold infinity

Lorsque la commande ipv6 multicast-routing est rentrée, le routeur va automatiquement configurer le protocole PIM sur chacune de ses interfaces. Il est possible de changer les valeurs par défaut avec les options "ipv6 pim".

La configuration de RP est nécessaire même si on utilise la technologie Embedded-RP car le routeur va monter les interfaces tunnels virtuels nécessaire pour le transit des paquets multicast. Il est conseillé de prendre les adresses des Loopback pour les points de rendez-vous car ces interfaces sont toujours "UP". Les commandes ci-dessus suffisent pour le cas où le routeur doit jouer le rôle de RP.

Si on utilise les adresses multicast temporaires, on peut utiliser des access-list qui vont choisir le point de rendez-vous suivant l'adresse du flux.

Voici un exemple d'utilisation d'access-list :
ipv6 pim rp-address 2001:4C18:20::1 list1
ipv6 pim rp-address 2001:4C18:20::2 list2
ipv6 access-list list1
sequence 20 permit ipv6 any FF1E:40:2001:4C18:20:1::/96
ipv6 access-list list2
sequence 20 permit ipv6 any FF1E:40:2001:4C18:20:2::/96

Pour tester les configurations, on peut voir les messages PIM échangés entre les routeurs grâce à la commande "debug ipv6 pim". Pour quitter ce mode, il suffit de rentrer "no debug ipv6 pim".
Pour voir la table de routage multicast, il faut entrer la commande "show ipv6 mroute". Par exemple :

R38-PE-2#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State
(*, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:00:58/00:02:35, RP 2001:4C18:20::2, flags: SC
Incoming interface: Tunnel1
RPF nbr: 2001:4C18:20::2
Immediate Outgoing interface list:
GigabitEthernet0/0, Forward, 00:00:58/never
GigabitEthernet0/1, Forward, 00:00:54/00:02:35
(2001:4C18:20:1:221:86FF:FE52:D383, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:00:51/00:03:29, flags: SJ
Incoming interface: Loopback6
RPF nbr: FE80::213:C3FF:FE7D:2110
Inherited Outgoing interface list:
GigabitEthernet0/0, Forward, 00:00:58/never
GigabitEthernet0/1, Forward, 00:00:54/00:02:35
(2001:4C18:20:2:21A:4BFF:FE63:3894, FF7E:240:2001:4C18:20:0:FFFF:FFFF), 00:00:55/00:02:34, flags: SFJT
Incoming interface: GigabitEthernet0/0
RPF nbr: 2001:4C18:20:2:21A:4BFF:FE63:3894
Inherited Outgoing interface list:
GigabitEthernet0/1, Forward, 00:00:54/00:02:35

== Exemple de configuration multicast IPv6 dans un cœur MPLS ==

Il faut assigner des adresses IPv6 à chaque interconnexion entre les PEs et les routeurs P et à chaque Loopback des routeurs. En effet, si l'interface n'a pas d'adresse IPv6, le routeur ne va pas implémenter le protocole PIM sur elle. Ensuite il est nécessaire d’implémenter un protocole de routage dynamique pour construire la table de routage que les messages PIM utiliseront lors de la construction de l’arbre multicast.

Ici, le protocole OSPF a été choisi pour sa simplicité d'implémentation. Voici les commandes qu'il faut entrer :

ipv6 router ospf 1
router-id 192.168.127.1
log-adjacency-changes detail
!

Pour le "router-id", il suffit de mettre l'adresse IPv4 de la Loopback. Ensuite il faut indiquer sur chaque interface où on veut que l'adresse soit partagée :

interface GigabitEthernet0/1
descrition Vers_le_routeur_P
ip address 192.168.11.2 255.255.255.0
ip router isis
duplex auto
speed auto
media-type rj45
ipv6 address 2001:4C18:2C:1::2/64
ipv6 enable
ipv6 ospf 1 area 0
mpls label protocol ldp
mpls ip
!
!

Le but étant d'obtenir ce type d'architecture :

[[Image:ArchiOSPFoverMPLS.jpg|thumb|center|600px|Figure 11-1 ''Configuration OSPF'']]

Et le schéma entier de l’architecture mise en place donne ceci :
[[Image:ArchiMPLS.jpg|thumb|center|600px|Figure 11-1 ''Architecture cœur MPLS'']]

== Autres solutions ==
L’utilisation de 6vPE peut être une solution définitive. Le principe de 6vPE repose sur l’établissement de vrf (voir [[Réseaux_privés_virtuels_IPv6_sur_MPLS | 6vPE]]). Il n’est pas possible aujourd’hui de configurer des RP dans une vrf. Du coup comme les clients viennent des interfaces incluses dans une vrf, le RP ne voit pas la demande d’inscription du client. Par contre, pour l’IPv4, les routeurs cisco offrent déjà des fonctionnalités bien plus compatibles avec le multicast puisqu’on peut configurer un RP dans une vrf. Il faut donc attendre une mise-à-jour de Cisco pour peut-être offrir une solution d’architecture où le routeur P n’a pas besoin d’implémenter d’interface IPv6.

File:ArchiOSPFoverMPLS.jpg

2009-12-21T09:44:17Z

Mcoic:

File:ArchiMPLS.jpg

2009-12-21T09:42:53Z

Mcoic: Exemple de coeur MPLS

Exemple de coeur MPLS

TdMbis

2009-12-21T09:28:53Z

Mcoic: /* Multicast */

TdMbis

2009-12-18T14:57:44Z

Mcoic: /* Multicast */

TdMbis

2009-12-18T14:53:57Z

Mcoic: /* Multicast */

TdMbis

2009-12-18T14:53:33Z

Mcoic: /* Routage */

=Table des matières=

''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.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =
* [[AdressageBis-Fondamentaux|Aspects Fondamentaux de l'Adressage]]
* [[AdressageBis-MeO|Mises en Oeuvre]]
* [[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) =
* [[Format du paquet IPv6]]
* [[Format du message ICMPv6]]
* [[Exemples de paquets]]

= Configuration automatique et contrôle (Laurent Toutain) =
* [[Protocole de Découverte des voisins]]
* [[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) =

= Supports de transmission (Laurent Toutain) =
= Routage =

= Multicast =

==Format des adresses multicast IPv6==

===Généralités ===

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.

[[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 :

* 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.
* 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 :

* 1 - node-local
* 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===

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.

[[image:CS100.gif]]

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>.

Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :

* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP,...) et
* 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===

Les adresses temporaires sont des adresses multicast IPv6 dont le bit T est positionné à 1. Il existe plusieurs types d'adresses temporaires :

* 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]]

: 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 :

** <tt>res</tt> (Reservé) : Les 4 bits de ce champ sont positionnés à <tt>0</tt>.
** <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.
** <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),
** <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>
** <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]].
: 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).
* 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).

[[image:CS103.gif]]

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.

{|
|+ Récapitulatif des types d'adresses multicast définis
! Préfixe || Usage
|-
|FF0X::/16 || Adresses IPv6 multicast permanentes
|-
|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 =

TdMbis

2009-12-18T14:52:27Z

Mcoic: /* Multicast */

=Table des matières=

''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.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =
* [[AdressageBis-Fondamentaux|Aspects Fondamentaux de l'Adressage]]
* [[AdressageBis-MeO|Mises en Oeuvre]]
* [[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) =
* [[Format du paquet IPv6]]
* [[Format du message ICMPv6]]
* [[Exemples de paquets]]

= Configuration automatique et contrôle (Laurent Toutain) =
* [[Protocole de Découverte des voisins]]
* [[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) =

= Supports de transmission (Laurent Toutain) =
= Routage =
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.

= Multicast =

==Format des adresses multicast IPv6==

===Généralités ===

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.

[[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 :

* 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.
* 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 :

* 1 - node-local
* 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===

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.

[[image:CS100.gif]]

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>.

Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :

* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP,...) et
* 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===

Les adresses temporaires sont des adresses multicast IPv6 dont le bit T est positionné à 1. Il existe plusieurs types d'adresses temporaires :

* 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]]

: 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 :

** <tt>res</tt> (Reservé) : Les 4 bits de ce champ sont positionnés à <tt>0</tt>.
** <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.
** <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),
** <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>
** <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]].
: 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).
* 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).

[[image:CS103.gif]]

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.

{|
|+ Récapitulatif des types d'adresses multicast définis
! Préfixe || Usage
|-
|FF0X::/16 || Adresses IPv6 multicast permanentes
|-
|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 =

TdMbis

2009-12-18T14:50:27Z

Mcoic: /* Multicast */

=Table des matières=

''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.''

''Initialement, l'édition papier était le support de base, l'édition électronique n'était qu'un moyen simple et rapide d'avoir accès à l'information. Avec la disparition des éditions O'Reilly France, l'édition électronique est devenue le seul moyen d'avoir accès au contenu du livre. Le site web doit donc être mieux structuré pour permettre une lecture plus linéaire.''

''Systématiquement les chapitres seront divisés en plusieurs sections reprenant la structuration suivante: ''
*'' Spécifications : Il s'agit de donner l'essentiel de l'information qui servira au plus grand nombre. Il ne faut pas se focaliser sur l'historique, ni sur les aspects recherches.''
* ''Mises en oeuvre : Il s'agit de mettre en pratique les informations fournies dans spécification. Elle concerne les grandes familles de produits (Linux, BSD, XP/Vista, Mac OS X, Cisco, Juniper,...)''
* ''Questions ouvertes : Faire le point sur les aspects controversés''
* ''Sujets de recherche : Décrire les aspects plus pointus qui sont en discussion pour la standardisation ou font l'objet de travaux de recherche plus amont.''
* ''Références : Reprise des normes et draft sité dans le chapitre, plus d'autres documents complémentaires venant d'autres sources que le G6.''
* ''Tutoriaux/Etudes de cas : Sujet de TP, description d'une mise en oeuvre, QCM,...''

= [[Glossaire|Glossaire (TOUS LES EDITEURS)]] =

= [[PréambuleBis|Préambule]] =

=[[IntroBis|Introduction]] =

= Adressage (Laurent Toutain) =
* [[AdressageBis-Fondamentaux|Aspects Fondamentaux de l'Adressage]]
* [[AdressageBis-MeO|Mises en Oeuvre]]
* [[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) =
* [[Format du paquet IPv6]]
* [[Format du message ICMPv6]]
* [[Exemples de paquets]]

= Configuration automatique et contrôle (Laurent Toutain) =
* [[Protocole de Découverte des voisins]]
* [[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) =

= Supports de transmission (Laurent Toutain) =
= Routage =
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.

==Format des adresses multicast IPv6==

===Généralités ===

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.

[[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 :

* 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.
* 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 :

* 1 - node-local
* 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===

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.

[[image:CS100.gif]]

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>.

Le RFC 2375 définit déjà certaines adresses IPv6 multicast. Deux types d'adresses multicast permanentes sont à distinguer :

* des adresses correspondant à des services de niveau réseau (comme NTP, DHCPv6, cisco-rp-announce, SAP,...) et
* 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===

Les adresses temporaires sont des adresses multicast IPv6 dont le bit T est positionné à 1. Il existe plusieurs types d'adresses temporaires :

* 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]]

: 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 :

** <tt>res</tt> (Reservé) : Les 4 bits de ce champ sont positionnés à <tt>0</tt>.
** <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.
** <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),
** <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>
** <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]].
: 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).
* 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).

[[image:CS103.gif]]

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.

{|
|+ Récapitulatif des types d'adresses multicast définis
! Préfixe || Usage
|-
|FF0X::/16 || Adresses IPv6 multicast permanentes
|-
|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 =