Choix d’adresse de source pour le protocole de
découverte d’écoutant de diffusion groupée (MLD)

Statut du présent mémoire

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright

Copyright (C) The Internet Society (2003). Tous droits réservés.

Résumé

Il est apparu qu’il y a un problème de choix d’une adresse de source IPv6 convenable pour les messages de découverte d’écoutant de diffusion groupée (MLD, Multicast Listener Discovery) lorsque un nœud effectue l’autoconfiguration d’adresse sans état. Le présent document est destiné à préciser les règles de choix d’une adresse IPv6 à utiliser pour les messages MLD.

1. Introduction

La spécification originale du protocole de découverte d’écouteur de diffusion groupée (MLD, Multicast Listener Discovery Protocol) pour IPv6 [RFC2710] rend obligatoire l’utilisation d’une adresse de source IPv6 de liaison locale pour la transmission des messages MLD. De plus, MLD exige aussi des nœuds qu’ils envoient des messages de rapport MLD lorsque ils se joignent à un groupe de diffusion groupée IPv6 (sauf à l’adresse Tous-les-nœuds et aux adresses de portée inférieure à 2).

Ces exigences de MLD entrent en conflit avec l’utilisation de la diffusion groupée IPv6 au sein du protocole de découverte de voisin [RFC2461]. Pour l’autoconfiguration sans état, telle que définie dans la [RFC2462], il est exigé d’un nœud qu’il se joigne à plusieurs groupes de diffusion groupée IPv6 afin d’effectuer la détection d’adresse dupliquée avant son utilisation. Comme la seule adresse qu’a le nœud est à l’essai, et ne peut pas être utilisée pour la communication, il n’a pas d’adresse convenable à utiliser comme adresse de source.

Le présent document va préciser les règles de choix d’adresse de source IPv6 à utiliser avec MLD lorsque il n’y a pas d’adresse de liaison locale disponible.

2. Terminologie

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC2119].

3. Justification

Dans la [RFC2710], la section 3 exige que tous les messages MLD soient envoyés avec une adresse de source IPv6 de liaison locale valide. Cependant, un nœud qui est en train d’effectuer la détection d’adresse dupliquée pour son adresse de liaison locale (LL) n’en aura pas de disponible pour l’utiliser comme adresse de source. Pour cette raison, le présent document permet d’utiliser l’adresse non spécifiée comme adresse de source pour les messages MLD qui sont utilisés durant la détection d’adresse dupliquée.

La discordance entre les règles définies dans la [RFC2710] et dans la [RFC2462] a conduit à des problèmes de mise en œuvre. Plusieurs mises en œuvre de IPv6 sautent l’envoi de messages de rapport MLD durant la détection d’adresses dupliquées parce qu’elles n’ont pas d’adresse de liaison locale valide. Cela conduit à des problèmes de fonctionnement lorsque un nœud est rattaché à des commutateurs qui effectuent la surveillance de MLD. Dans ce scénario, la détection d’adresse dupliquée (DAD, duplicate address detection) va bien se terminer et des collisions peuvent survenir une fois que l’adresse est mise en service parce que les commutateurs peuvent n’avoir pas transmis tous les messages DAD à tous les nœuds de la liaison comme requis. Le présent document règle ce problème en spécifiant que les rapports MLD sont à envoyer en utilisant une adresse de source non spécifiée avant le début de la DAD afin de s’assurer que les messages envoyés aux adresses de diffusion groupée LL (par exemple, en incluant MLD) sont transmis à tous les nœuds appropriés comme demandé.

4. Lignes directrices pour le choix d’adresse de source MLD

Un nœud qui comprend MLD est obligé de choisir une adresse de source IPv6 convenable pour tous les messages MLD (Rapport, Fait, et Interrogation).

Les messages MLD Interrogation DOIVENT être envoyés avec une adresse de liaison locale valide comme adresse de source IPv6. Si un nœud (routeur ou hôte) reçoit un message d’interrogation avec une adresse de source IPv6 réglée à l’adresse non spécifiée (::) il DOIT éliminer en silence le message et DEVRAIT enregistrer une alerte dans son journal.

Les messages MLD Rapport et Fait sont envoyés avec une adresse de liaison locale comme adresse de source IPv6, si une adresse valide est disponible sur l’interface. Si une adresse de liaison locale valide n’est pas disponible (par exemple, il n’en a pas été configuré) le message est envoyé avec l’adresse non spécifiée (::) comme adresse IPv6 de source.

Une fois qu’une adresse de liaison locale valide est disponible, un nœud DEVRAIT générer un nouveau message Rapport MLD pour toutes les adresses de diffusion groupée jointes sur l’interface.

Les routeurs qui reçoivent un message MLD Rapport ou Fait avec l’adresse non spécifiée comme adresse de source IPv6 DOIVENT éliminer en silence le paquet sans effectuer aucune action sur le contenu du paquet.

Les routeurs qui surveillent DOIVENT gérer l’état de transmission de diffusion groupée sur la base des messages MLD Rapport et Fait envoyés avec l’adresse non spécifiée comme adresse de source IPv6.

5. Implications du choix d’adresse de source

Dans la RFC2710, les messages MLD Rapport et Fait sont obligés d’avoir une adresse de source IPv6 qui soit de liaison locale. Le présent mémoire augmente cette règle en permettant que ces messages contiennent l’adresse non spécifiée (::) comme adresse de source.

Le comportement des mises en œuvre de la RFC2710 lors de la réception d’un message avec une adresse de source de :: dépend de la façon dont la mise en œuvre traite l’adresse non spécifiée. C’est-à-dire que ces messages seront abandonnés si la mise en œuvre ne considère pas l’adresse non spécifiée comme étant de portée de liaison locale.

Comme l’adresse non spécifiée n’est utilisée que lorsque il n’y a pas d’adresse de liaison locale, les mises en œuvre de la RFC2710 qui éliminent ces paquets n’auront pas d’effet sur l’envoyeur du paquet car cette utilisation ne devrait être que pour joindre le groupe de diffusion groupée de liaison locale sollicité par le nœud [RFC2462].

Il y a une implication pour les envoyeurs en ce qui concerne la jonction à d’autres groupes de diffusion groupée avant l’activation d’une adresse de liaison locale. L’élimination des messages Rapport qui utilisent l’adresse non spécifiée comme adresse de source pourrait causer une perte du trafic de diffusion groupée qui est espéré par le nœud. Ce trou noir sera temporaire jusqu’à ce que le nœud puisse envoyer un message Rapport avec une adresse de liaison locale valide.

6. Considérations pour la sécurité

Les questions générales de sécurité qui se rapportent à MLD sont exposées dans la [RFC2710].

Pour les hôtes et les routeurs, tous les messages MLD reçus d’une adresse de source non spécifiée sont éliminés en silence. C’est le comportement exigé par la [RFC2710] et il n’est pas changé par le présent document. Donc, les changements n’ont pas de nouvel impact sur la sécurité.

Dans le cas des commutateurs de surveillance, l’état de transmission de diffusion groupée sera maintenu sur la base des messages Rapport et Fait envoyés avec l’adresse non spécifiée comme adresse de source. Cependant, les faiblesses de la sécurité sont similaires dans ce scénario à celles qui décrivent des messages falsifiés dans la section Considérations pour la sécurité de la [RFC2710].

7. Déclaration de droits de propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’IETF au sujet des droits dans les documents en cours de normalisation et se rapportant aux normes figurent dans le BCP 11.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, brevet ou applications de brevets, ou autres droits de propriété qui pourraient recouvrir la technologie qui pourrait être nécessaire pour mettre en œuvre la présente norme. Prière d’adresser les informations au directeur exécutif de l’IETF.

8. Références

8.1 Références normatives

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2710] S. Deering, W. Fenner et B. Haberman, "Découverte d'écouteur de diffusion groupée (MLD) pour IPv6", octobre 1999.

8.2 Références pour information

[RFC2461] T. Narten, E. Nordmark, W. Simpson, "Découverte de voisins pour IP version 6 (IPv6)", décembre 1998. (Obsolète, voir RFC4861) (D.S.)

[RFC2462] S. Thomson, T. Narten, "Autoconfiguration d'adresse IPv6 sans état", décembre 1998. (Obsolète, voir RFC4862) (D.S.)

9. Adresse de l’auteur

Brian Haberman

Caspian Networks

753 Bridgewater Drive

Sykesville, MD 21784

USA

téléphone : 410-552-1421

mél : brian@innovationslab.net

10. Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2003). Tous droits réservés.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.