Aller au contenu principal

3. Considérations relatives à IPv6 (IPv6 Considerations)

Afin d'éviter toute confusion, les discussions précédentes étaient fondées exclusivement sur IPv4. Le protocole équivalent pour IPv6 est la découverte des écouteurs multicast (Multicast Listener Discovery) [MLD]. Comme MLD est fondé sur IGMP, la description complète et les recommandations ne sont pas répétées ici ; seuls les cas où MLD diffère d'IGMP sont signalés.

Les règles de transfert de contrôle et de données décrites pour IGMP à la section 2 peuvent être appliquées à MLD avec quelques considérations ; autrement dit, la fonctionnalité de base consistant à intercepter les messages MLD et à construire les listes d'appartenance et de routeurs multicast est la même que pour IGMP.

Le transfert de données IPv6 est plus simple que celui d'IPv4 à un égard : MLD est obligatoire pour les adresses de portée 2 (locale au lien) et supérieure. La seule exception est l'adresse locale au lien de tous les hôtes FF02::1, qui n'envoie jamais de messages MLD ; les paquets destinés à l'adresse locale au lien de tous les hôtes DEVRAIENT (SHOULD) être transférés sur tous les ports.

Les groupes dont les adresses se situent dans FF00::/15 (ce qui couvre FF00::/16, réservé, et FF01::/16, local au nœud) n'envoient pas de messages MLD ; ces adresses ne devraient donc jamais apparaître dans les paquets sur le lien.

Les différences suivantes entre IPv4 et IPv6 sont pertinentes pour le snooping :

  1. Le protocole de maintenance des groupes multicast IPv6 s'appelle Multicast Listener Discovery version 2 [MLDv2]. MLDv2 utilise des types de messages ICMPv6 au lieu des types de messages IGMP.

  2. [IPV6-ETHER] et [IPV6-FDDI] décrivent comment les 32 bits de l'adresse IP de destination (DIP) de 128 bits sont utilisés pour former l'adresse MAC de destination (DMAC) de 48 bits ; [IPV6-TOKEN] décrit la correspondance pour les adresses DMAC Token Ring à l'aide des trois bits de poids faible ; et [IPV6-1394] utilise un numéro de canal de 6 bits.

  3. La découverte des routeurs multicast est effectuée par le protocole MRDISC tel que défini dans [MRDISC].

De façon équivalente aux comportements IPv4 concernant l'adresse source IP nulle, les rapports d'appartenance MLD NE DOIVENT PAS (MUST NOT) être rejetés par un commutateur de snooping MLD au motif que l'adresse IP source est non spécifiée (::). En outre, si un commutateur non Querier usurpe des requêtes générales (comme indiqué à la section 2.1 ci-dessus, pour les changements de topologie du spanning tree), il DEVRAIT (SHOULD) utiliser l'adresse IP source non spécifiée (::) lors de l'envoi de ces requêtes. Lorsque de telles requêtes mandatées sont reçues, elles NE DOIVENT PAS (MUST NOT) être prises en compte dans le processus d'élection du Querier.

L'en-tête IPv6 ne comporte pas de champ de somme de contrôle. Toutefois, un commutateur DEVRAIT (SHOULD) détecter, dans la mesure du possible, d'autres problèmes d'intégrité des paquets, tels que la cohérence entre la version d'adresse et la longueur de charge utile. Si de telles erreurs sont détectées, les informations du paquet NE DOIVENT PAS (MUST NOT) être intégrées à la table de transfert MLD, et le code de transfert DEVRAIT (SHOULD) rejeter le paquet et prendre les mesures de suivi raisonnables évoquées précédemment.

Comme MLDv2 utilise ICMPv6, et qu'ICMPv6 a plusieurs autres usages que MLD, se fier uniquement au champ next-header de l'en-tête IP pour déterminer si un paquet concerne le snooping MLD ne suffit plus. Une implémentation logicielle qui traite tous les paquets ICMPv6 comme des candidats au snooping MLD peut facilement saturer les files de réception et bloquer le processeur, ce qui va à l'encontre de l'objectif de la fonction de snooping, et entraîne la perte de paquets non MLD destinés à d'autres hôtes.

Deux approches sont possibles :

  1. Exiger que le commutateur examine plus profondément le contenu du paquet. Cette approche est préférable lorsqu'une option de configuration permet à l'administrateur de préciser quels types de paquets ICMPv6 doivent déclencher une redirection vers le processeur ; coder en dur les types de paquets manque de souplesse pour l'introduction de nouveaux types à l'avenir.

  2. Combiner la détection ICMPv6 avec l'adresse DMAC multicast. Cette approche risque de classer à tort comme MLD de nouveaux protocoles utilisant ICMPv6 avec une adresse DMAC multicast.

La première approche est recommandée. Si une telle option de configuration ne peut pas être fournie, les implémenteurs DEVRAIENT (SHOULD) envisager sérieusement de l'ajouter, car les messages de découverte de voisins (Neighbor Discovery) relèvent de la catégorie susceptible d'être mal classée, et ils sont essentiels à l'intégrité opérationnelle des réseaux IPv6.

L'attribution initiale des adresses multicast IPv6, telle que décrite dans [RFC3307], ne couvre que les 32 bits de poids faible de l'identifiant de groupe. La correspondance entre les adresses multicast IP et les adresses DMAC multicast présente donc un important recouvrement. La structure d'une adresse multicast IPv6 est la suivante :

   |   8    |  4 |  4 |             112 bits                  |
   +--------+----+----+---------------------------------------+
   |11111111|flgs|scop|             group ID                  |
   +--------+----+----+---------------------------------------+

Ainsi, sur Ethernet et FDDI, 2 ** (112 - 32), soit plus de 1,2e24 adresses DIP uniques, correspondent à une même adresse DMAC, contre 2**5 pour IPv4. Toutefois, selon [RFC3307], l'attribution initiale des adresses multicast IPv6 ne couvre que les 32 bits de poids faible de l'identifiant de groupe ; cela limite temporairement le problème d'ambiguïté aux identifiants de groupe ayant des valeurs de drapeaux et de portée différentes, mais la politique d'attribution pourrait changer à l'avenir. Compte tenu de ce recouvrement potentiel, un transfert fondé sur les adresses IPv6 plutôt que sur les adresses MAC est recommandé.