Groupe de travail Réseau	R. Kermode, Motorola	
Request for Comments : 2907	septembre 2000	
Catégorie : En cours de normalisation	Traduction Claude Brière de L'Isle	

Option MADCAP d'état de recouvrement de portée de diffusion groupée

Statut du présent mémoire
La présente RFC spécifie un protocole de normalisation pour la communauté Internet et appelle à des discussions et suggestions pour son amélioration. Prière de se reporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémore n’est soumise à aucune restriction.

Déclaration de copyright
Copyright (C) The Internet Society (2000). Tous droits réservés.

Résumé
Le présent document définit une nouvelle option pour le protocole d'allocation de client dynamique d'adresse de diffusion groupée (MADCAP, Multicast Address Dynamic Client Allocation Protocol) pour la prise en charge de possibilités incorporées. L'objet de la nouvelle option est de permettre aux clients d'apprendre quelles possibilités sont incorporées dans chacun d'eux, et donc elle peut être utilisée pour étendre les recherches de possibilités ou le transport hiérarchisé de diffusion groupée.

Table des Matières 

1.	Introduction
1.1	Effet d'horizon partagé de la portée par durée de vie (TTL)
1.2	Éliminer l'effet d'horizon partagé avec la portée administrative
1.3	Terminologie
2.	État de limitation de portée incorporée de diffusion groupée
3	Option d'état d'incorporation de portée de diffusion groupée
3.1	Option de liste de portée de diffusion groupée
3.2	Représentation de l'état d'incorporation de portée de diffusion groupée
3.3	Utilisation de l'option d'état d'incorporation de portée de diffusion groupée
4.	Gestion de l'incorporation dynamique de portée
4.1	Traitement des messages MZAP par le serveur MADCAP
4.2	Mise à jour de l'état des portée dynamiques due à l'expiration du temporisateur
5.	Format de l'option d'état d'incorporation de portée de diffusion groupée
6.	Constantes
7.	Considérations pour la sécurité
8.	Considérations relatives à l'IANA
9.	Remerciements
10.	Références
11.	Adresse de l'auteur
12.	Déclaration de droits de reproduction

1.	Introduction

Le protocole d'allocation dynamique d'adresse de client de diffusion groupée (MADCAP, Multicast Address Dynamic Client Allocation Protocol) [RFC2730] permet aux applications client la capacité de demander des services d'allocation d'adresses de diffusion groupée à des serveurs d'allocation d'adresses de diffusion groupée. Au titre de l'architecture d'allocation d'adresse de diffusion groupée [RFC2908], MADCAP donne aux clients la capacité de réserver, demander, et étendre les emprunts d'adresses de diffusion groupée.

Une nouvelle option MADCAP, l'option "d'état de recouvrement de portée de diffusion groupée" (Multicast Scope Nesting State) est proposée pour permettre aux clients d'apprendre non seulement quelles portées existent via l'option "Liste de portées de diffusion groupée" (Multicast Scope List) existante, mais aussi comment ces portées s'incorporent les unes dans les autres. Cette nouvelle option donnera aussi aux clients la capacité de faire de meilleurs choix de portées pour une session donnée et aussi de construire des hiérarchies de zones dessinées administrativement. Ces hiérarchies peuvent alors être utilisées pour effectuer des recherches d'expansion de portée au lieu des recherches par anneau d'expansion ou de TTL croissant. Les recherches à expansion de portée ne souffrent pas de l'effet d'horizon partagé présent dans les recherches par anneau d'expansion, et donc à la fois simplifient la conception du protocole et fournissent une meilleure localisation.

1.1	Effet d'horizon partagé de la portée par durée de vie (TTL)

Les techniques de recherche en diffusion groupée et de transport à récupération localisée qui s'appuient sur la portée du TTL sont connues pour peiner lorsqu'elles sont déployées à grande échelle. La faille est l'effet d'horizon partagé que montre la Figure 1 ci-dessous. Un demandeur et un répondant doivent chacun utiliser un TTL qui soit suffisamment grand pour qu'ils s'atteignent l'un l'autre. Lorsque ils sont séparés par de nombreux bonds, le TTL devient grand et le nombre de receveurs dans l'arborescence de diffusion groupée qui ne reçoivent que la demande ou que la réponse peut devenir très grand.

                      .......   *******
                   ...       ***       ***        A entend seulement S
                 ..        **   ..        **      B entend S et R
                .         *       .         *     C entend seulement R
               .         *         .         *
               .         S<------->R         *    . Limite de TTL pour S
               .         *         .         *    * Limite de TTL pour R
                .    A    *   B   .   C     *
                 ..        **   ..        **
                   ...       ***       ***
                      .......   *******

Figure 1 : Problème de l'horizon partagé à partir de la portée du TTL
1.2	Éliminer l'effet d'horizon partagé avec la portée administrative

Idéalement, on a besoin pour résoudre ce problème d'un mécanisme qui élimine ou minimise la taille des régions A et C dans la Figure 1 comme le montre la Figure 2. Un mécanisme qui offre cette capacité est la portée administrative [RFC2365], dans laquelle les routeurs empêchent le passage de paquets au sein d'une certaine gamme d'adresses de diffusion groupée. Les routeurs qui n'ont pas ce dispositif peuvent être configurés pour fournir un périmètre autour d'une région du réseau. Ce périmètre est dit renfermer une zone à portée administrative à l'intérieur de laquelle le trafic envoyé à cette gamme particulière d'adresses de diffusion groupée ne peut ni sortir ni entrer. Les routeurs peuvent construire et gérer les zones à portée administrative en utilisant le protocole MZAP [RFC2776].

                           ........................
                  .                          .
                 .      nombreux bonds        .
                 .S<------------------------>R.
                 .                            .
                  .                          .
                    ........................

Figure 2 : Élimination de l'effet d'horizon partagé

MZAP comporte aussi la capacité de déterminer si des régions à portée limitée administrativement sont ou non incorporées dans une autre. Cela permet de construire des hiérarchies telles que celle montrée à la Figure 1.

        . . . . .  . . . . . . . . . . . . .
       .           portée a                 .     Frontière de portée
      .                                      .     . = portée a
     .  _______________      ________________ .    - = portées b,c
     . /   portée b    \    / portée c        \ .  # = portées d,e,f et g
     .|                 \   |                  |.
     .| #######   ###### |  |#######   ####### |.
     .|#portée#  #portée#|  |#portée#  #portée#|.
      .\# d   #  # e   # /  |# f   #   #  g  #/.
       .\######  ######/    \ #####     #####/.
        .\____________/      \_____________/.
         . . . . . . . . . . . . . . . . .

Figure 3 : Exemple de hiérarchie de zones de portées administrativement limitées incorporées

Voici l'algorithme [KERM] de recherche générique par expansion de portée qui exploite l'existence d'une hiérarchie de zones à limitation de portée administrative.

1)	En commençant par la plus petite portée connue pour la session, un demandeur dans cette session produit une demande et attend une réponse.

2)	Si un nœud au sein de cette portée entend une demande à une certaine portée qu'il peut satisfaire, il envoie une réponse à la même portée, éventuellement après un certain délai aléatoire pour réduire les duplications de réponses.

3)	Les nœuds qui reçoivent une réponse à une demande particulière alors qu'ils attendent pour envoyer une réponse à cette demande suppriment leur propre réponse.

4)	Si un demandeur produit une demande à une portée, et n'entend pas de réponse après une durée spécifiée, il retransmet sa demande à la même portée un petit nombre de fois supplémentaires. Si ces essais devaient échouer à provoquer une réponse, le demandeur augmenterait la portée à la portée immédiatement supérieure et recommencerait.

5)	Les demandeurs augmentent la portée de la demande conformément à l'étape 4 jusqu'à ce qu'une réponse soit reçue ou que la plus longue portée légale pour la session soit atteinte. Si les tentatives pour provoquer une réponse à la plus longue portée possible pour la session devaient échouer à donner une réponse, le demandeur pourrait conclure que la demande ne peut pas être satisfaite.

1.3	Terminologie

Dans le présent document, les mots clé "DOIT", "NE DOIT PAS", "EXIGE", "DEVRAIT" NE DEVRAIT PAS", "RECOMMANDÉ", "NON RECOMMANDÉ", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans la [RFC2119].

Dans tout le reste du présent document, les mots "serveur" ou "serveur MADCAP" se réfèrent à un hôte qui fournit des services d'allocation d'adresses de diffusion groupée via MADCAP. Les mots "client" ou "client MADCAP" se réfèrent à un hôte qui demande des services d'allocation d'adresses de diffusion groupée via MADCAP.

2.	État de limitation de portée incorporée de diffusion groupée

Deux portées, X et Y, peuvent en relation de quatre façons possibles.

1)	X est incorporé dans Y.
2)	Y est incorporé dans X,
3)	X et Y ne s'incorporent pas (le cas du chevauchement),
4)	X et Y s'incorporent l'une l'autre.

Le quatrième cas DEVRAIT être interprété comme signifiant que X et Y ont exactement la même frontière. Cela ne signifie pas que X et Y ont la même portée dans la mesure où X et Y peuvent correspondre à des gammes différentes de l'espace d'adresses de diffusion groupée.

Cet état DOIT être mémorisé dans les serveurs MADCAP qui DOIVENT permettre la mise à jour de l'état lorsque les conditions du réseau changent. Chaque serveur MADCAP DEVRAIT donc définir deux états qui décrivent si "la portée X s'incorpore dans la portée Y" et vice versa. Pour la suite du présent document, les relations d'incorporation seront notées avec "/" où X/Y définit la relation "X incorporé dans Y". Cette relation devra être comprise comme prenant une des valeurs "vrai" ou "faux". L'état de relation d'incorporation qui est indéterminé est considéré comme "faux".

3	Option d'état d'incorporation de portée de diffusion groupée 

L'option "État d'incorporation de portée de diffusion groupée" est proposée pour augmenter l'option "Liste de portée de diffusion groupée" au sein du protocole MADCAP en fournissant aux applications des informations supplémentaires sur la façon dont s'incorporent les portées. L'option proposée est FACULTATIVE, c'est-à-dire que les serveurs MADCAP PEUVENT mettre en œuvre cette nouvelle option, sans qu'ils soient cependant obligés de le faire.

Les serveurs MADCAP doivent acquérir ces informations d'incorporation supplémentaires au moyen de la configuration statique ou via quelque autre protocole tel que MZAP [RFC2776] qui gèrent les portées administratives de façon dynamique.

3.1	Option de liste de portée de diffusion groupée

Pour comprendre l'option "État d'incorporation de portée de diffusion groupée" on doit d'abord comprendre l'option "Liste de portée de diffusion groupée".

L'option Liste de portée de diffusion groupée dans MADCAP est utilisée par les serveurs MADCAP pour informer les clients MADCAP des zones qui sont visibles. Les portées visibles sont énumérées dans l'option comme des tuplets successifs, où chaque tuplet comporte les informations suivantes :

o	Identifiant de portée :
	La plus petite adresse pour la gamme d'adresses de diffusion groupée couverte par cette portée.

o	Dernière adresse :
	La plus grande adresse pour la gamme d'adresses de diffusion groupée couverte par cette portée.

o	TTL :
	Le TTL à utiliser lors de l'envoi de messages à cette portée.

o	Nom(s) :
	Un ou plusieurs noms spécifiques d'une langue pour la portée.

3.2	Représentation de l'état d'incorporation de portée de diffusion groupée

Soit une liste de portées de diffusion groupée qui contient les descriptions de n portées, on peut former n(n-1)/2 appariements. Comme on l'a montré à la section 2 chaque appariement peut prendre un état parmi les quatre possibles. Et donc, pour une liste de n portées, il existe deux éléments d'information pour chaque appariement pour un total de n(n-1) éléments d'information qui disent quelles portées s'incorporent ou non dans chaque autre.

Il y a plusieurs façons de représenter cet état en utilisant des matrices pleines, des matrices éparses, et en utilisant des listes de listes de longueur variable. Pour une efficacité et une souplesse maximales, l'option d'état d'incorporation de portée de diffusion groupée utilise une approche de matrice d'empaquetage de bits. Dans cette approche, une matrice est construite en utilisant des pièces de l'état X/Y où X est la rangée et Y est la colonne. Un "1" dans la matrice signifie que la relation "rangée incorporée dans la colonne" est vraie, alors que un "0" signifie que cette relation est soit fausse, soit indéterminée. La diagonale de la matrice est retirée, car c'est le cas où X est le même que Y, et chaque rangée est alors bourrée avec des zéros jusqu'à la prochaine limite d'octet pour donner la représentation finale.

Voici un exemple de la façon dont une matrice serait construite pour les incorporations de portée suivantes S1/S2, S2/S3, S2/S4, S3/S5, S4/S5, S5/S6, et S6/S7. Noter qu'un certain nombre de relations d'incorporations supplémentaires sont impliquées à partir de cet ensemble.

                         ________________________________
                        /............          \    \    \
                       /.S3 _________._____     \    \    \
                      |.   /+--+    \ .    \    |    |    |
                      |.  | |S1| S2 | . S4 | S5 | S6 | S7 |
                      |.   \+--+    / .    |    |    |    |
                       \.   \______/ .     |    |    |    |
                        \....\.......      /    /    /    /
                         \    \___________/    /    /    /
                          \___________________/    /    /
       \ Y                 \______________________/    /
      X \ 1 2 3 4 5 6 7     \_________________________/
         +-+-+-+-+-+-+-+
      1  |1 1 1 1 1 1 1|      *111111       1111 1100       0xfc
      2  |0 1 1 1 1 1 1|      0*11111       0111 1100       0x7c
      3  |0 0 1 0 1 1 1|      00*0111       0001 1100       0x1c
      4  |0 0 0 1 1 1 1|  =>  000*111   =>  0001 1100   =>  0x1c
      5  |0 0 0 0 1 1 1|      0000*11       0000 1100       0x0c
      6  |0 0 0 0 0 1 1|      00000*1       0000 0100       0x04
      7  |0 0 0 0 0 0 1|      000000*       0000 0000       0x00
         +-+-+-+-+-+-+-+                           ^^
                          * = X/Y où   bourrage de zéros
                             X == Y
        Représentation finale : 0xfc 0x7c 0x1c 0x1c 0x0c 0x04 0x00

Figure 4 : Exemple d'incorporation de portées
3.3	Utilisation de l'option d'état d'incorporation de portée de diffusion groupée

L'option "État d'incorporation de portée de diffusion groupée" dépend de l'option "Liste de portées de diffusion groupée". Cette décision résulte du raisonnement suivant. L'option État d'incorporation de portée de diffusion groupée exige que les portées soient identifiées ainsi que leurs propriétés d'incorporation. Comme les informations nécessaires pour décrire une portée sont contenues dans l'option Liste de portées de diffusion groupée et que ces informations peuvent changer, les messages MADCAP qui contiennent l'option État d'incorporation de portée de diffusion groupée doivent être atomiques et doivent donc inclure l'option "Liste de portées de diffusion groupée".

Et donc, l'option "État d'incorporation de portée de diffusion groupée" DOIT être utilisée dans les seuls messages qui portent l'option "Liste de portées de diffusion groupée", à savoir :

ACK (en réponse à GETINFO)

Comme l'option État d'incorporation de portée de diffusion groupée dépend de l'option Liste de portées de diffusion groupée, elle NE DOIT PAS être incluse sans l'option Liste de portées de diffusion groupée.

Les clients qui ont besoin d'apprendre explicitement les relations d'incorporation entre les portées devraient donc envoyer un message GETINFO au serveur avec les codes d'option "Liste de portées de diffusion groupée" ET "État d'incorporation de portée de diffusion groupée" énumérés dans une option Demande d'option.

4.	Gestion de l'incorporation dynamique de portée

Les portées peuvent être configurées manuellement ou automatiquement. Lorsque les portées sont configurées manuellement, les relations entre elles seront aussi statiques, en supposant que le réseau ne subit pas de partition du fait d'une défaillance de routeur. Si le réseau devait subir une partition ou des dommages après une partition, il est très vraisemblable que les relations d'incorporation changeraient. Les relations d'incorporation de portées vont aussi changer lorsque un réseau est rejeté ou lorsque un changement est fait délibérément à un routeur soit par une reconfiguration manuelle soit par quelque moyen automatique.

Pour s'assurer que les relations d'incorporation sont correctement déterminées lorsque les frontières des portées subissent un changement, les serveurs MADCAP DOIVENT inclure un mécanisme qui permette :
a)	d'annoncer aux clients MADCAP si la décision d'incorporation est encore en débat ou si elle peut être considérée comme définitive.
b)	si pour une entrée d'état d'incorporation particulière une portée ou les deux ont été détruites, de détruire l'état d'incorporation.
c)	si les frontières de la portée ont été changées de telle sorte que si la portée X est ou non incorporée dans la portée Y, c'est l'opposé qui est vrai maintenant.

Pour réaliser a) et b) les serveurs MADCAP DOIVENT mettre en œuvre les deux temporisateurs suivants :
NEST_NO_DECISION_TIMER, 
ZONES_EXIST_TIMER.

Le premier temporisateur, NEST_NO_DECISION_TIMER, est utilisé pour marquer le temps écoulé entre la première fois qu'un serveur MADCAP entend parler d'une portée et la prise d'une décision sur ses relations avec les autres zones. Jusqu'à l'arrivée à expiration de ce temporisateur, les serveurs MADCAP NE DOIVENT PAS conclure que la portée est incorporée dans une autre.

Le temporisateur NEST_NO_DECISION_TIMER va aussi être utilisé pour mesurer la durée de l'état X/Y = "faux" pour permettre à X/Y d'être remis à vrai dans le cas où les frontières pour la zone X et la zone Y changent de telle sorte que le zone X soit maintenant incorporée dans la zone Y.

Le second temporisateur ZONES_EXIST_TIMER sera utilisé pour compter le temps de l'état interne entre deux portées dans le cas où une portée ou les deux seraient détruites.

4.1	Traitement des messages MZAP par le serveur MADCAP

Lorsque MZAP est utilisé pour découvrir les relations d'incorporation entre des portées, les serveurs MADCAP vont surveiller les messages MZAP qui sont transmis périodiquement par les routeurs frontière de zone (ZBR, Zone Border Router) durant le cours normal de la maintenance administrative des frontières de portée. De cette façon, ils seront capables d'apprendre quelles portées existent (via les messages d'annonce de zone, (ZAM, Zone Announcement Message) et quelles portées ne sont pas incorporées (via les messages Pas dedans (NIM, Not Inside Message)). Cet état doit être mis en antémémoire au sein du serveur MADCAP.

Lorsque un serveur MADCAP S reçoit un NIM d'une ZBR contenant l'information que la portée X n'est pas incorporée dans la portée Y, il DOIT mettre à jour son état interne de la façon suivante :
1)	S DOIT mettre à jour son état X/Y interne à "faux".
2)	S DOIT relancer le temporisateur NEST_NO_DECISION_TIMER pour l'état X/Y qui vient d'être mis à jour.

4.2	Mise à jour de l'état des portée dynamiques due à l'expiration du temporisateur

Les serveurs MADCAP vont mettre à jour l'état d'incorporation de X/Y à l'arrivée à expiration des temporisateurs de la façon suivante .

o	Si le temporisateur NEST_NO_DECISION_TIMER arrive à expiration pour une entrée d'état X/Y ET que aucun message MADCAP n'a été reçu pour indiquer que la portée X n'est pas incorporée dans la portée Y, un serveur MADCAP S DOIT conclure que la portée X est incorporée dans la portée Y. Il en résulte que S va changer X/Y de "faux" à "vrai". Lorsque un changement d'état de "faux" à "vrai" survient pour X/Y, S doit aussi lancer le temporisateur ZONES_EXIST_TIMER pour X/Y. Le temporisateur ZONES_EXIST_TIMER ne devrait être remis à zéro que lorsque un message d'annonce de zone (ZAM) a été reçu pour les deux zones X et Y depuis la dernière fois qu'il a été redémarré. Cela assure que les deux zones X et Y sont connues pour exister encore.

o	Si le temporisateur ZONES_EXIST_TIMER arrive à expiration pour une entrée d'état X/Y, S DEVRAIT conclure que ni la zone Y ni la zone X n'existent plus et donc que les états X/Y et Y/X devraient tous deux être détruits.

5.	Format de l'option d'état d'incorporation de portée de diffusion groupée

           Code     Longueur  Compte  Matrice d'état d'incorporation
      +-----+-----+-----+-----+-----+-----+-...-+-----+
      |    17     |     p     | m   | N1  |     | Nm  |
      +-----+-----+-----+-----+-----+-----+-...-+-----+

Code : 16 bits
Identifiant d'option 17.

Longueur : 16 bits
C'est la longueur de l'option en octets.

Compte : 8 bits
C'est le nombre de zones présentes dans la matrice d'état d'incorporation. Cette valeur DOIT être identique à celle du champ Compte dans l'option Liste d'état de diffusion groupée précédente. Si ce n'est pas le cas, les informations d'état d'incorporation de portée DOIVENT être ignorées.

Matrice d'état d'incorporation :
C'est la représentation du paquetage binaire compressé de la matrice, déduite de la même manière que montré à la Figure 4. Noter que pour N portées, la matrice compressée sera N fois ceil((N-1)/8) octets de long, où ceil() est la fonction qui arrondit à l'entier le plus proche. Les portées qui correspondent aux rangées et colonnes de cette matrice figurent dans le même ordre que celui dans lequel elles apparaissent dans l'option Liste de portées de diffusion groupée.

6.	Constantes

[NEST_NO_DECISION_TIMER]
C'est la durée après laquelle un serveur ou client MADCAP peut supposer qu'un message qui annonce que deux zones ne sont pas incorporées ne sera plus reçu. La durée de ce temporisateur dépend du protocole d'annonce de zone utilisé pour informer le routeur MADCAP des zones qui existent actuellement. Lorsque MZAP [RFC2776] est utilisé, cette valeur devrait être supérieure à la valeur de temporisation MZAP NIM-INTERVAL + 30 %. Cela correspond à une valeur de temporisation de 1800 + 30% = 2340 secondes (39 minutes).

[ZONES_EXIST_TIMER] 
C'est la durée après laquelle un serveur ou client MADCAP devrait supposer que la zone en question n'existe pas lorsque les zones sont détectées de façon dynamique. La durée de ce temporisateur dépend du protocole d'annonce de zone utilisé pour informer le routeur MADCAP des zones qui existent actuellement. Lorsque MZAP [RFC2776] est utilisé, cette valeur ne devrait pas être inférieure à celle du temporisateur MZAP NIM-HOLDTIME, qui fait par défaut 5460 secondes (91 minutes).

7.	Considérations pour la sécurité

Comme le présent document propose une extension au protocole MADCAP via l'ajout d'une nouvelle option, le même ensemble de problèmes de sécurité s'y applique.

En plus de ces problèmes, il y a ceux qui vont survenir lorsque les informations dans l'option d'état de recouvrement de portée de diffusion groupée seront falsifiées. Dans ce cas, les clients seront mal informés quant aux portées qui se recouvrent. Le client va alors prendre des décisions incorrectes en ce qui concerne l'ordre dans lequel utiliser les portées. Cela aura pour effet d'utiliser des portées plus longues que nécessaire, ce qui va effectivement écraser toute hiérarchie de portées présente et annuler les avantages apportés par la présence de la hiérarchie.

Et donc une option d'état de recouvrement de portée de diffusion groupée mal formée ou altérée peut être cause que les protocoles qui s'appuient sur l'existence d'une hiérarchie de portées se proportionnent moins bien, mais cela ne les empêchera pas de fonctionner.

8.	Considérations relatives à l'IANA

Le code d'option MADCAP 17 a été alloué par l'IANA à l'option d'état de recouvrement de portée de diffusion groupée (Multicast Nesting State) [RFC2730].

9.	Remerciements

L'auteur tient à remercier Mark Handley et Dave Thaler pour les discussions constructives et les remarques qui ont aidé à donner forme et à préciser le présent document.

10.	Références
(Les liens hypertexte en tête de référence pointent sur l'original anglais, ceux du corps de l'intitulé sur la version française)

[KERM]	R. Kermode, "Smart Network Caches: Localized Content and Application Negotiated Recovery Mechanisms for Multicast Media Distribution", Thèse de doctorat, MIT Media Laboratory, juin 1998.

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

[RFC2365]	D. Meyer, "Diffusion groupée sur IP limitée administrativement", (BCP0023), juillet 1998.

[RFC2730]	S. Hanna, B. Patel, M. Shah, "Protocole d'allocation dynamique d'adresse de client de diffusion groupée (MADCAP)", décembre 1999. (P.S.)

[RFC2776]	M. Handley, D. Thaler, R. Kermode, "Protocole d'annonce de zone à portée de diffusion groupée (MZAP)", février 2000. (P.S.)

[RFC2908]	D. Thaler, M. Handley, D. Estrin, "Architecture d'allocation d'adresse de diffusion groupée Internet", septembre 2000. (Info.)

11.	Adresse de l'auteur

Roger Kermode
Motorola Australian Research Centre
Locked Bag 5028
Botany, NSW 1455
Australia
mél : Roger.Kermode@motorola.com

12.	Déclaration de droits de reproduction

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

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent paragraphe soient inclus dans toutes copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de copyright ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le développement des normes Internet, auquel cas les procédures de copyright définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies 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 ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

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