# NRP : TD4

###### tags: `NRP` `S2`

## 3 IPv6 Multicast Group Management

1. C'est MLD (Multicast Listener Discovery) ([RFC3810](https://tools.ietf.org/html/rfc3810)) qui est utilisé
C'est un sous protocole d'ICMPv6
Il y a deux verisons de ce protocole :
- MLDv1 (Similaire a IGMPv2): Gestion des abonnements multicast sans precision de la source.
- MLDv2 (Similaire a IGMPv3): Gestion des abonnements multicast avec precision explicite de la source.

2. Multicast Listener Query (routeur uniquement): used to learn multicast address listener information from an attached link
Multicast Listener Report: State Change Reports are retransmitted several times => robustness
Multicast Done : Leave the multicast group

1er message : Multicast Listener Report
- @source : `fe80::c601:dff:fe7f:0`
- @destination : ``ff02::16``
- Link-Local
- All MLDv2-capable routers
- type : 143
- scope : link-local scope (ff0**2** [Voir](https://hackmd.io/PmJ1dffdRguDvj6HH6Jt4Q?both#Pour-le-scope-des-adresses-multicast-))
- meaning : MLDv2 reports (https://tools.ietf.org/html/rfc3810 page 26)
- lifetime : permanent (ff**0**2 : donc les flags ORPT sont tous a 0)
- exclude : précise une adresse dont on ne veut pas recevoir de message (=> Number of Sources: 1); s'il n'y a aucune source de préciser (=> Number of Sources: 0), cela veut dire que l'on accepte de recevoir des messages de toutes les sources
- include : On inclut le traffic de une/plusieurs source.s

2ème message : Multicast Listener Query
- @source : ``fe80::c601:dff:fe7f:0``
- @destination : ``ff08::275``
- Organization-Local
- 275 => on ecoute sauf l'@ ``2001:192:40:40::175``
- type : 130

### Pour le scope des adresses multicast :

Les flags sont :
- O : Reserved
- R : Rendez-vous point
- P : network Prefix
- T : Transient (0 : Permanent addresses, 1: NonPermanent addresses)

3. Les messages sont envoyés toute les 125s (QQIC: Querier's Query Interval Code). En cas de changement les modifications sont envoyées directement sans attendre un Query.

**Question supplémentaire: En regardant la figure 1.a le device qui envoye ces messages est une hote ou un routeur ?**
-> router car @Dest commence par ff02:: (All routers on the local network segment)

ff02::2 --> @ multicast pour tous les routeurs
ff02::1 ---> multicast pour tous les devices

Exclude: par défaut on accepte tous les messages des adresses sauf celles qu'on spécifies
Multicast @ record Include on a besoin de connaitre les @ IP des sources, pour l'exclude pas besoin

Mais aussi avec la souscription a l'@ ``ff02::d``, les hotes ne souscrivent pas a une @ destinée pour tous les routers PIM

**Question supplémentaire : Quel protocol de routage multicast est active sur le routeur dans le message de la Fig. 1?**

Dans les Records, on ecoute sur les @ ``ff02::d`` -> PIM et ``ff02::16`` -> MLDv2

**Remarques**
- Un message de type Query peut etre envoye que par un routeur
- Un routeur va toujours souscrire a l'addresse multicast ff02::2, ça montre que le device qui envoie le MLD Report c'est un routeur: un hote va jamais souscrire a l'adresse ff02::d (all PIM Routers)

## 4 IPv6 Multicast Routing

0. Source based tree (Different tree from each sender to receivers) et Groupe-Shared tree (Same tree used by all group members)

1.
- Il y a **PIM Dense Mode** : Part du principe que quand une source commence à envoyer, tout les systèmes qui reçoivent veulent recevoir les messages multicasts, il n'a donc pas besoin de phase de découverte de topologie.
Il utilise 3 étapes :
-> Flood : envoie des données dans toutes les routes possible "inondation"
-> Prune : "Elagage" des routes prises par les données non "RPF"= Reverse path forwarding, c'est-à-dire ignorer les paquets ne venant pas d'une interface qui aurait été utilisée pour router le paquet
-> Assert : Sert à supprimer les doublons

https://networklessons.com/multicast/multicast-pim-dense-mode

* **PIM Sparse Mode** : Construit un arbre différent pour chaque source. Les hosts doivent rejoindre le groupe multicast.
- Chaque destinataire doit rejoindre le groupe en envoyant un join au RendezVous Point (désigné automatiquement ou manuellement et racine de la diffusion en multicast).
- Ensuite le RP met un lien vers la destination qui a rejoint le groupe sur son interface de sortie
- Quand la source envoie des données, elle envoie un register au RP
- Le RP envoie les données sur l"arbre partagé en envoyant join vers la source
- Le RP fait register stop quand il reçoit les données
- Si il y a un chemin plus court le noeud qui reçoit les données envoie un join vers un noeud ayant une distance plus courte
- Le noeud qui reçoit le join envoie ses données sur les 2 interfaces
- Le noeud qui reçoit les données envoie un prune sur le chemin le plus long

2. https://tools.ietf.org/html/rfc4601#section-3.1
=> Rendezvous Point (RP):
An RP is a router that has been configured to be used as the root of the non-source-specific distribution tree for a multicast group. Join messages from receivers for a group are sent towards the RP, and data from senders is sent to the RP so that receivers can discover who the senders are and start to receive traffic destined for the group.

3.

Le récetpteur T1 veut recevoir des informations de la source S. Il prévient donc le router R6 qui envoie un PIM Join(*,G) à R5 qui l'envoie à RP.
*Join(* * *,G) signifie que l'on veut rejoindre le groupe G pour n'importe quelle source* *

RP crée un lien vers R6 avec une sortie par R5 avec les paquets Arbre RPT.

La source S veut envoyer des données, R1 encapsule les données et envoie un register vers RP par R2
RP crée un lien (S,G) vers R1 il envoie un join vers la source. R1 et R2 crée l'état (S,G).
Une fois que les données arrive au RP, il envoie un register-stop, sinon il recoit les données en double.
Les données arrivent au récépteur T1, et il veut un chemin plus court. R6 envoie un join vers la source.
R6 fait passer le join par R5 et R3 puis arrive à R1.
R5 et R6 reçoivent (S,G) et R6 envoie un Prune vers le RP
R1 envoie ses données simultanément à travers R2 et R3.
Une fois l'élaguage fini, la source transmet les données par R1->R3->R5->R6