Groupe de travail Réseau	B. Fenner, AT&T Research	
Request for Comments : 4605	H. He, Nortel	
Catégorie : Sur la voie de la normalisation	B. Haberman, JHU-APL	
Traduction Claude Brière de L'Isle	H. Sandick, Little River Elementary School	
	août 2006	

Transmission de diffusion groupée fondée sur la découverte d'écoutant de diffusion groupée (MLD) du protocole de gestion de groupe Internet (IGMP) ("mandataire IGMP/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 (2006).

Résumé
Dans certaines topologies, il n'est pas nécessaire d'utiliser un protocole d'acheminement de diffusion groupée. Il est suffisant à un appareil d'apprendre et de déléguer les informations sur les membres du groupe et de simplement transmettre les paquets en diffusion groupée sur la base de ces informations. Le présent document décrit un mécanisme pour transmettre sur la seule base des informations d'appartenance du protocole de gestion de groupe Internet (IGMP, Internet Group Management Protocol) ou du protocole de découverte d'écoutant de diffusion groupée (MLD, Multicast Listener Discovery).
Table des matières
1. Introduction	1
1.1 Motivation	2
1.2 Déclaration d'applicabilité	2
1.3 Conventions	2
2. Définitions	3
2.1 Interface amont	3
2.2 Interface aval	3
2.3 Mode de groupe	3
2.4 Abonnement	3
2.5 Base de données des membres	3
3. Définition abstraite du protocole	3
3.1 Restrictions de topologie	4
3.2 Envoyeurs prenant en charge	5
4. Comportement des appareils mandataires	5
4.1 Base de données des membres	5
4.2 Transmission des paquets	6
4.3 Considérations de diffusion groupée spécifique de source	6
5 Considérations sur la sécurité	6
6. Remerciements	6
7. Références normatives	6
8. Références pour information	7
Adresse des auteurs	7
Déclaration complète de droits de reproduction	7

 	1.	Introduction

Le présent document applique l'acheminement de diffusion groupée par arbre d’expansion [MCAST] à un environnement de protocole de gestion de groupe Internet (IGMP) ou de découverte d'écoutant de diffusion groupée (MLD) seul. La topologie se limite à une arborescence, car on ne spécifie aucun protocole pour construire un arbre d’expansion sur une topologie plus complexe. La racine de l'arborescence est supposée être connectée à une infrastructure de diffusion groupée plus large.

 	1.1	Motivation
Dans une simple topologie arborescente, il n'est pas nécessaire de faire fonctionner un protocole d'acheminement de diffusion groupée. Il est suffisant d'apprendre et de déléguer les informations sur les membres du groupe et de simplement transmettre les paquets de diffusion groupée sur la base de ces informations. Un exemple typique d'une telle topologie arborescente peut être trouvé dans un boîtier d'agrégation d'extrémité tel qu'un multiplexeur d'accès de ligne d'abonné numérique (DSLAM, Digital Subscriber Line Access Multiplexer). Dans la plupart des scénarios de déploiement, un boîtier d'extrémité a seulement une connexion au côté cœur de réseau et a de nombreuses connexions côté client.

Utiliser la transmission fondée sur IGMP/MLD pour dupliquer le trafic de diffusion groupée sur des appareils comme les boîtiers d'extrémité peut grandement simplifier la conception et la mise en œuvre de ces appareils. En ne prenant pas en charge des protocoles d'acheminement de diffusion groupée plus compliqués comme la diffusion groupée indépendante du protocole (PIM, Protocol Independent Multicast) ou le protocole d'acheminement de diffusion groupée par vecteur de distance (DVMRP, Distance Vector Multicast Routing Protocol) cela réduit non seulement le coût des appareils mais aussi la charge de fonctionnement. Un autre avantage est que cela rend les appareils mandataires indépendants du protocole d'acheminement de diffusion groupée utilisé par les routeurs du cœur de réseau. Donc, les appareils mandataires peuvent être facilement déployés dans tout réseau de diffusion groupée.

La robustesse dans un boîtier d'extrémité est généralement réalisée par l'utilisation d'une connexion de réserve au cœur de réseau. Quand la première connexion a une défaillance, le boîtier d'extrémité se replie sur la seconde connexion. La transmission fondée sur IGMP/MLD peut bénéficier de ce mécanisme et utiliser la connexion de réserve comme connexion redondante ou de secours sur les routeurs de diffusion groupée. Quand un boîtier d'extrémité se replie sur la seconde connexion, la connexion au mandataire amont peut aussi être mise à jour sur la nouvelle connexion.

 	1.2	Déclaration d'applicabilité
La transmission fondée sur IGMP/MLD ne fonctionne que dans une topologie d'arborescence simple. L'arborescence doit être configurée manuellement en désignant des interfaces vers l'amont et vers l'aval sur chaque appareil mandataire. De plus, le schéma d'adressage IP appliqué à la topologie d'arborescence de mandataires DEVRAIT être configuré de façon à assurer qu'un appareil mandataire peut gagner l'élection d'interrogateur IGMP/MLD pour être capable de transmettre le trafic de diffusion groupée. Il n'y a pas d'autre routeur de diffusion groupée à part les appareils mandataires dans l'arborescence, et la racine de l'arborescence est supposée être connectée à une infrastructure de diffusion groupée plus large. Ce protocole est limité à un seul domaine administratif.

Dans des scénarios plus compliqués où la topologie n'est pas une arborescence, où un mécanisme de repli sur défaillance plus robuste est désirable, ou où plus d'un domaine administratif est impliqué, un protocole d'acheminement de diffusion groupée devrait être utilisé.

 	1.3	Conventions
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Le présent document a été produit par le groupe de travail Multicast & Anycast Group Membership (MAGMA) au sein de l'IETF (Internet Engineering Task Force). Des commentaires sont sollicités et devraient être adressés à la liste de diffusion du groupe de travail à magma@ietf.org et/ou aux auteurs.

 	2.	Définitions
 	2.1	Interface amont
L'interface d'un appareil mandataire dans la direction de la racine de l'arborescence. Aussi appelée "interface d'hôte".

 	2.2	Interface aval
Chaque interface d'un appareil mandataire qui n'est pas dans la direction de la racine de l'arborescence. Aussi appelée "interface routeur".

 	2.3	Mode de groupe
Dans les environnements IPv4, pour chaque groupe de diffusion groupée, un groupe est en mode IGMP version 1 (IGMPv1) [RFC1112] si un rapport IGMPv1 est entendu. Un groupe est en mode IGMP version 2 (IGMPv2) [RFC2236] si un rapport IGMPv2 est entendu mais si pas de rapport IGMPv1 n'est entendu. Un groupe est en mode IGMP version 3 (IGMPv3) [RFC3376] si un rapport IGMPv3 est entendu mais pas de rapport IGMPv1 ou IGMPv2 n'est entendu.

Dans les environnements IPv6, pour chaque groupe de diffusion groupée, un groupe est en mode MLD version 1 (MLDv1) [RFC2710] si un rapport MLDv1 est entendu. MLDv1 est équivalent à IGMPv2. Un groupe est en mode MLD version 2 (MLDv2) [RFC3810] si un rapport MLDv2 est entendu mais pas de rapport MLDv1. MLDv2 est équivalent à IGMPv3.

 	2.4	Abonnement
Quand un groupe est en mode IGMPv1 ou IGMPv2/MLDv1, l'abonnement est une adhésion au groupe sur une interface. Quand un groupe est en mode IGMPv3/MLDv2, l'abonnement est une entrée d'état IGMPv3/MLDv2, c'est-à-dire, un quadruplet (adresse de diffusion groupée, temporisateur de groupe, mode de filtre, liste d'éléments de source) sur une interface.

 	2.5	Base de données des membres
La base de données tenue à chaque appareil mandataire dans laquelle les informations sur les membres de chacune de ses interfaces aval sont fusionnées. La base de données des membres est un ensemble d'enregistrements des membres de la forme : (adresse de diffusion groupée, mode de filtre, liste de sources)

Se référer aux spécifications de IGMPv3/MLDv2 [RFC3376], [RFC3810] pour la définition des champs "mode de filtre" et "liste de sources". Les comportements opérationnels de la base de données des membres sont définis au paragraphe 4.1.

 	3.	Définition abstraite du protocole

Un appareil mandataire qui effectue la transmission fondée sur IGMP/MLD a une seule interface en amont et une ou plusieurs interfaces en aval. Ces désignations sont explicitement configurées ; il n'y a pas de protocole pour déterminer de quel type est chaque interface. Il effectue la portion routeur du protocole IGMP [RFC1112], [RFC2236], [RFC3376] ou MLD [RFC2710], [RFC3810] sur ses interfaces aval, et la portion hôte de IGMP/MLD sur son interface amont. L'appareil mandataire NE DOIT PAS effectuer la portion routeur de IGMP/MLD sur son interface amont.

L'appareil mandataire tient une base de données consistant en la fusion de tous les abonnements sur toute interface aval. Se reporter à la Section 4 pour les détails de la construction et la maintenance de la base de données des membres.

L'appareil mandataire envoie des rapports d'adhésion IGMP/MLD sur l'interface amont quand il est interrogé et envoie des rapports non sollicités ou des déclarations de départ quand la base de données change.

Quand l'appareil mandataire reçoit un paquet destiné à un groupe de diffusion groupée (canal dans la diffusion groupée spécifique de source (SSM, Source-Specific Multicast)) il utilise une liste consistant en l'interface amont et toute interface aval qui a un abonnement relevant de ce paquet et sur laquelle il est l'interrogateur IGMP/MLD. Cette liste peut être construite dynamiquement ou mise en antémémoire. Il retire de la liste l'interface sur laquelle ce paquet est arrivé et transmet le paquet aux interfaces restantes (cela peut inclure l'interface en amont).

Noter que la règle qu'un appareil mandataire doit être l'interrogateur afin de transmettre des paquets restreint le schéma d'adressage IP utilisé ; en particulier, l'appareil qui transmet sur la base de IGMP/MLD doit avoir la plus basse des adresses IP de tout interrogateur IGMP/MLD potentiel sur la liaison, afin de gagner l'élection d'interrogateur IGMP/MLD. La règle d'élection d'interrogateur IGMP/MLD définit que l'interrogateur qui a la plus basse adresse IP gagne l'élection. (La règle d'élection d'interrogateur IGMP/MLD est définie dans les spécifications IGMP/MLD au titre du comportement IGMP/MLD.) Donc, dans un environnement de transmission seule fondée sur IGMP/MLD, si un appareil non mandataire gagne l'élection d'interrogateur IGMP/MLD, aucun paquet ne va s'écouler.

Par exemple, la figure ci-dessous montre un environnement de transmission seule fondée sur IGMP/MLD:

           LAN 1  --------------------------------------
                  Amont |                 | Amont   
                        A(non mandataire) B(mandataire)
                  Aval  | (plus basse IP) | aval  
           LAN 2  --------------------------------------

L'appareil A a la plus basse adresse IP sur le LAN 2, mais il n'est pas un appareil mandataire. Conformément à la règle d'élection d'interrogateur IGMP/MLD, A va gagner l'élection sur le LAN 2 car il a la plus basse adresse IP. L'appareil B ne va pas transmettre le trafic au LAN 2 car il n'est pas l'interrogateur sur le LAN 2.

L'élection d'un seul mandatire de transmission est nécessaire pour éviter des boucles locales et du trafic redondant pour les liaisons qui sont considérées comme des liaisons en aval par plusieurs transmetteurs fondés sur IGMP/MLD. Cette règle "porte" l'élection du transmetteur sur l'élection d'interrogateur IGMP/MLD. L'utilisation du processus d'élection de l'interrogateur IGMP/MLD pour choisir le mandataire transmetteur donne une fonctionnalité similaire sur la liaison locale au mécanisme d'assertion PIM. Sur une liaison avec un seul appareil transmetteur fondé sur IGMP/MLD, cette règle PEUT être désactivée (c'est-à-dire, l'appareil PEUT être configuré à transmettre des paquets à une interface sur laquelle il n'est pas l'interrogateur). Cependant, la configuration par défaut DOIT inclure la règle d'interrogateur, par exemple, pour des besoins de redondance, comme le montre la figure ci-dessous :

           LAN 1  --------------------------------------
                  Amont    |              | Amont
                           A              B
                  Aval     |              | Aval
           LAN 2  --------------------------------------

Le LAN 2 peut avoir deux appareils mandataires, A et B. Dans une telle configuration, un appareil mandataire doit être choisi pour transmettre les paquets. Le présent document exige que le transmetteur soit l'interrogateur IGMP/MLD. Donc l'appareil mandataire A va transmettre les paquets au LAN 2 seulement si A est l'interrogateur. Dans la figure ci-dessus, si A est le seul appareil mandataire, A peut être configuré à transmettre les paquets même si c'est B qui est l'interrogateur.

Noter que cela ne protège pas contre une boucle "en amont". Par exemple, dans la figure ci-dessous :

           LAN 1  --------------------------------------
                  Amont    |              | Aval 
                           A              B
                  Aval     |              | Amont
           LAN 2  --------------------------------------

B va transmettre inconditionnellement les paquets du LAN 1 au LAN 2, et A va transmettre inconditionnellement les paquets du LAN 2 au LAN 1. Cela va causer une boucle en amont. Un protocole d'acheminement de diffusion groupée qui emploie un algorithme de construction d'arborescence est nécessaire pour résoudre des boucles comme celle là.

 	3.1	Restrictions de topologie
La présente spécification décrit un protocole qui fonctionne seulement dans une topologie d'arborescence simple. L'arborescence doit être configurée manuellement par les interfaces amont et aval désignées sur chaque appareil mandataire, et la racine de l'arborescence est supposée être connectée à une infrastructure de diffusion groupée plus large.

 	3.2	Envoyeurs prenant en charge
Afin que les envoyeurs envoient de l'intérieur de l'arborescence de mandataire, tout le trafic est transmis vers la racine. Le ou les routeurs de diffusion groupée connectés à l' infrastructure de diffusion groupée plus large devraient être configurés à traiter tous les systèmes à l'intérieur de l'arborescence de mandataire comme si ils étaient directement connectés ; par exemple, pour la diffusion groupée indépendante du protocole - mode épars (PIM-SM) [RFC4601], ces routeurs devraient enregistrer-encapsuler le trafic provenant des nouvelles sources au sein de l'arborescence de mandataires tout comme ils le feraient pour des sources directement connectées.

Ces informations vont probablemnt être configurées manuellement ; la transmission de diffusion groupée fondée sur IGMP/MLD ne donne aucun moyen pour que les routeurs en amont de l'arborescence de mandataires sachent quels réseaux sont connectés à l'arborescence de mandataire. Si la topologie de mandataire est congruente à une topologie d'acheminement, cette information PEUT être apprise du protocole d'acheminement qui fonctionne sur cette topologie ; par exemple, un routeur peut être configuré à traiter les paquets de diffusion groupée provenant de tous les préfixes appris du protocole d'acheminement X via l'interface Y bien qu'ils viennent d'un système directement connecté.

 	4.	Comportement des appareils mandataires

Cette section décrit plus en détails les actions d'un appareil de transmission de diffusion groupée fondée sur IGMP/MLD.

 	4.1	Base de données des membres
L'appareil mandataire effectue la portion routeur du protocole IGMP/MLD sur chaque interface en aval. Pour chaque interface, la version de IGMP/MLD utilisé est explicitement configurée et est par défaut la plus haute version supportée par le système.

Le résultat de ce protocole est un ensemble d'abonnements ; cet ensemble est tenu séparément sur chaque interface en aval.  De plus, les abonnements sur chaque interface en aval sont fusionnés dans la base de données des membres.

La base de données des membres est un ensemble d'enregistrements de membres de la forme :

(adresse de diffusion groupée, mode filtre, liste de sources)

Chaque enregistrement est le résultat de la fusion de tous les abonnements pour l'adresse de diffusion groupée de cet enregistrement sur les interfaces en aval. Si certains abonnements sont IGMPv1 ou IGMPv2/MLDv1, ils sont convertis en abonnements IGMPv3/MLDv2. Les abonnements IGMPv3/MLDv2 et convertis sont d'abord pré traités pour supprimer les temporisateurs dans les abonnements et, si le mode filtre est EXCLU, pour supprimer chaque source dont le temporisateur de source est supérieur à 0. Ensuite les abonnements pré traités sont fusionnés en utilisant les règles de fusion pour membres multiples sur une seule interface (spécifiées au paragraphe 3.2 de la spécification IGMPv3 [RFC3376] et au paragraphe 4.2 de la spécification MLDv2 [RFC3810]) pour créer l'enregistrement d'adhésion. Par exemple, il y a deux interfaces aval, I1 et I2, qui ont des abonnements pour l'adresse de diffusion groupée G. I1 a un abonnement IGMPv2/MLDv1 qui est (G). I2 a un abonnement IGMPv3/MLDv2 qui a les informations d'adhésion (G, INCLUDE, (S1, S2)). L'abonnement de I1 est converti en abonnement IGMPv3/MLDv2 qui a les informations d'adhésion (G, EXCLUDE, NULL). Alors les abonnements sont pré traités et fusionnés, et l'enregistrement final d'adhésion est (G, EXCLUDE, NULL).

L'appareil mandataire effectue la portion hôte du protocole IGMP/MLD sur l'interface en amont. Si il y a un interrogateur IGMPv1 ou IGMPv2/MLDv1 sur le réseau en amont, alors l'appareil mandataire va effectuer IGMPv1 ou IGMPv2/MLDv1 sur l'interface en amont en conséquence. Autrement, il va effectuer IGMPv3/MLDv2.

Si l'appareil mandataire effectue IGMPv3/MLDv2 sur l'interface en amont, alors quand la composition de la base de données des membres change, le changement dans la base de données est rapporté sur l'interface en amont bien que cet appareil mandataire soit un hôte qui effectue l'action. Si l'appareil mandataire effectue IGMPv1 ou IGMPv2/MLDv1 sur l'interface en amont, alors les enregistrements de membres sont créés ou supprimés, les changements sont rapportés sur l'interface amont. Tous les autres changements sont ignorés. Quand l'appareil mandataire rapporte en utilisant IGMPv1 ou IGMPv2/MLDv1, seul est utilisé le champ Adresse de diffusion groupée dans l'enregistrement de membre.

 	4.2	Transmission des paquets
Un appareil mandataire transmet les paquets reçus sur son interface amont à chaque interface aval sur la base des abonnements de l'interface aval et de si cet appareil mandataire est ou non l'interrogateur IGMP/MLD sur chaque interface.  Un appareil mandataire transmet les paquets reçus sur toute interface aval à l'interface amont, et à chaque interface en aval autre que l'interface entrante sur la base des abonnements des interfaces en amont et de si cet appareil mandataire est ou non l'interrogateur IGMP/MLD sur chaque interface. Un appareil mandataire PEUT utiliser une antémémoire de transmission afin de ne pas prendre cette décision pour chaque paquet, mais DOIT mettre à jour l'antémémoire en utilisant ces règles chaque fois que les informations utilisées pour la construire changent.

 	4.3	Considérations de diffusion groupée spécifique de source
Pour prendre en charge la diffusion groupée spécifique de source (SSM, Source-Specific Multicast), l'appareil mandataire devrait être conforme à la spécification sur l'utilisation de IGMPv3 pour SSM [RFC4604]. Noter que l'appareil mandataire devrait être conforme à la fois aux exigences pour les hôtes IGMP et aux exigences de routeur IGMP pour SSM car il effectue la portion hôte IGMP sur l'interface en amont et la portion routeur IGMP sur chaque interface en aval.

Une interface peut être configurée à effectuer IGMPv1 ou IGMPv2. Dans ce scénario, la sémantique de SSM ne va pas être concervée pour cette interface. Cependant, un appareil mandataire qui prend en charge le présent document devrait ignorer ces abonnements IGMPv1 ou IGMPv2 envoyés aux adresses SSM. Et plus important, les paquets avec des adresses spécifiques de source NE DEVRAIENT PAS être transmis aux interfaces avec des abonnements IGMPv2 ou IGMPv1 pour ces adresses.

 	5	Considérations sur la sécurité

Comme seul l'interrogateur transmet les paquets, le processus d'élection d'interrogateur IGMP/MLD peut conduire à des trous noirs si un non transmetteur est élu interrogateur. Un attaquant sur un LAN aval peut provoquer son élection comme interrogateur, et par suite, aucun paquet ne va être transmis.

Cependant, il y a des moyens pour éviter ce problème. Il est très courant qu'un opérateur numérote les routeurs en commençant par le bas du sous réseau. Ainsi un opérateur DEVRAIT allouer les plus basses adresses IP du sous réseau à un ou des mandataires afin qu'ils gagnent l'élection d'interrogateur.

La transmission fondée sur IGMP/MLD ne fournit pas de mécanisme de détection de "boucle en amont" décrit dans la Section 3. Donc, pour éviter les problèmes causés par une "boucle en amont", il DOIT être administrativement assuré que de telles boucles n'existent pas lors du déploiement du système de mandataires IGMP/MLD.

Les informations IGMP/MLD présentées par le mandataire à ses routeurs en amont sont l'agrégation de toutes les informations de ses membres de groupe en amont. Tout contrôle d'accès appliqué au protocole d'adhésion de groupe au routeur en amont ne peut pas être effectué sur un seul abonné. C'est-à-dire, le contrôle d'accès va s'appliquer également à tous les hôtes intéressés accessibles via l'appareil mandataire.

 	6.	Remerciements

Les auteurs remercient Erik Nordmark, Dave Thaler, Pekka Savola, Karen Kimball, et les autres qui ont relu la spécification et fourni des commentaires.

 	7.	Références normatives

[RFC1112]	S. Deering, "Extensions d'hôte pour diffusion groupée sur IP", STD 5, août 1989. (Mise à jour par la RFC2236)

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

[RFC2236]	W. Fenner, "Protocole de gestion de groupe Internet, version 2", novembre 1997. (Remplacée par RFC3376)

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

[RFC3376]	B. Cain et autres, "Protocole Internet de gestion de groupe, IGMP version 3", octobre 2002. (P.S.)

[RFC3810]	R. Vida, L. Costa, éditeurs, "Découverte d'écouteur de diffusion groupée version 2 (MLDv2) pour IPv6", juin  2004.

[RFC4604]	H. Holbrook et autres, "Utilisation de la version 3 du protocole de gestion de groupe Internet (IGMPv3) et de la version  2 du protocole de découverte d'écoutant de diffusion groupée (MLDv2) pour la diffusion groupée spécifique de source", août 2006. (MàJ RFC3376, RFC3810) (P.S.)

 	8.	Références pour information

[MCAST]	Deering, S., "Multicast Routing in a Datagram Internetwork", Thèse de doctorat, Stanford University, décembre  1991.

[RFC4601]	B. Fenner et autres, "Diffusion groupée indépendante du protocole - Mode épars (PIM-SM) : spécification du protocole (Révisée)", août 2006. (Remplace RFC2362) (MàJ par RFC5059 ; Remplacée par RFC7761, STD83) (P.S.)

 	Adresse des auteurs

Bill Fenner	Haixiang He	
AT&T Labs - Research	Nortel	
1 River Oaks Place	600 Technology Park Drive	
San Jose, CA 95134	Billerica, MA  01821	
téléphone : +1 408 493-8505	USA	
mél : fenner@research.att.com 	mél : haixiang@nortel.com 	

Brian Haberman	Hal Sandick	
Johns Hopkins University Applied Physics Lab	Little River Elementary School	
11100 Johns Hopkins Road	2315 Snow Hill Road	
Laurel, MD  20723-6099	Durham, NC  27712	
mél : brian@innovationslab.net 	mél : sandick@nc.rr.com 	

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2006).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

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’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

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, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement 
Le financement de la fonction d’édition des RFC est fourni par l'activité de soutien administatif (IASA) de l'IETF.