Groupe de travail Réseau	M. Handley, ACIRI	
Request for Comments : 2776	D. Thaler, Microsoft	
Catégorie : En cours de normalisation	R. Kermode, Motorola	
Traduction Claude Brière de L'Isle	février 2000	

Protocole d'annonce de zone de diffusion groupée à portée limitée (MZAP)

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émoire 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 le protocole d'annonce de zone de diffusion groupée à portée limitée (MZAP, Multicast-Scope Zone Announcement Protocol) pour la découverte des zones de diffusion groupée à portée limitée administrativement qui sont pertinentes pour une localisation particulière. MZAP fournit aussi des mécanismes par lesquels peuvent être découvertes les malformations courantes des zones à limitation administrative de portée.

Table des Matières

1.	Introduction
2.	Terminologie
3.	Généralités
3.1	Incorporation de portée
3.2	Autres messages
3.3	Identifiants de zone
4.	Détection de mauvaise configuration de routeur
4.1	Détection de zones de portée non convexes
4.2	Détection de fuite dans des frontières de portées non locales
4.3	Détection d'une fuite sur une zone de portée locale
4.4	Détection de conflit de zone de portée
5.	Format des paquets
5.1	Message d'annonce de zone
5.2	Limite de zone dépassée (ZLE)
5.3	Message de convexité de zone
5.4	Message Pas-dedans
6.	Règles de traitement des messages
6.1	Entités internes qui écoutent les messages MZAP
6.2	Envoi de ZAM
6.3	Réception de ZAM
6.4	Envoi des ZLE
6.5	Réception des ZLE
6.6	Envoi des ZCM
6.7	Réception des ZCM
6.8	Envoi des NIM
6.9	Réception des NIM
7.	Constantes
8.	Considérations pour la sécurité
9.	Remerciements
10.	Références
11.	Adresse des auteurs
12.	Déclaration de droits de reproduction

1.	Introduction

L'utilisation de la diffusion groupée sur IP à limitation administrative de portée, telle que définie dans la RFC 2365 [1], permet aux paquets d'être adressés à une gamme spécifique d'adresses de diffusion groupée (par exemple, 239.0.0.0 à 239.255.255.255 pour IPv4) de telle sorte que les paquets ne traversent pas les frontières configurées administrativement, et permet aussi à de telles adresses d'être allouées localement et donc il n'est pas nécessaire qu'elles soient uniques dans les frontières administratives. Cette propriété de dénomination logique permet la réutilisation d'adresse tout autant que la capacité que des services d'infrastructure tels que l'allocation d'adresse, l'annonce de session, et la localisation de service utilisent des adresses bien connues qui sont certaines d'avoir une signification locale au sein de toute organisation.

La gamme des adresses à portée limitée administrativement peut être subdivisée par les administrateurs de façon que plusieurs niveaux de frontières administratives puissent être simultanément pris en charge. Il en résulte qu'une "portée de diffusion groupée" est définie dans une gamme particulière d'adresses à laquelle a été donnée une signification topologique.

Pour prendre en charge un tel usage, un routeur à une frontière administrative est configuré avec un ou plusieurs filtres par interface, ou "limites de portées de diffusion groupé". Avoir une telle frontière sur une interface signifie qu'elle ne va pas transmettre les paquets qui correspondent à une gamme configurée d'adresses de diffusion groupée dans l'une ou l'autre direction de l'interface.

Une zone spécifique de la topologie de réseau qui est à l'intérieur d'une frontière pour une portée donnée est appelée une "zone de portée de diffusion groupée". Comme les mêmes gammes peuvent être réutilisées au sein de zones disjointes du réseau, il peut y avoir de nombreuses "zones de portée de diffusion groupée" pour toute portée de diffusion groupée donnée. Une zone de portée peut avoir zéro, un ou plusieurs noms textuels (dans différentes langues) pour la portée, pour le lecteur humain. Par exemple, si la gamme 239.192/14 était allouée pour s'étendre sur un réseau d'entreprise entier, on pourrait lui donner (en interne) le nom "Portée Privée SuperSA".

Les zones à portée limitée administrativement peuvent être de toutes tailles, et un hôte particulier peut se trouver dans de nombreuses zones à portée limitée administrativement (pour des portées différentes, c'est-à-dire, pour des gammes d'adresses qui ne se chevauchent pas) de diverses tailles, pour autant que les zones de portées qui se coupent topologiquement ne se coupent pas dans la gamme d'adresses.

Les applications et les services sont intéressés par divers aspects des portées dans lesquelles elles résident :

o	Les applications qui proposent aux utilisateurs le choix de la portée de leur fonctionnement (par exemple, lors de la création d'une nouvelle session, si elle doit être confinée à un intranet d'entreprise, ou si elle doit aller sur l'Internet public) sont intéressée aux noms textuels qui ont une signification pour l'utilisateur.

o	Les services qui utilisent des adresses de diffusion groupée "relatives" (comme définies dans [1]) dans toutes les portées sont intéressés à la gamme d'adresses utilisée par chaque portée, de sorte qu'ils puissent appliquer un décalage constant et calculer quelle adresse utiliser dans chaque portée.

o	Ceux qui allouent les adresses sont intéressés par la gamme des adresses, et à savoir si il leur est permis d'allouer des adresses sur toute la gamme ou non.

o	Certaines applications et services peuvent aussi être intéressées par les relations d'incorporation entre les portées. Par exemple, la connaissance des relations d'incorporation peut être utilisée pour effectuer des recherches "d'expansion de portée" d'une façon similaire, mais d'un meilleur comportement, à celle de la recherche d'anneau d'expansion bien connue où le TTL d'une demande est régulièrement augmenté jusqu'à trouver quelqu'un qui réponde. Les études ont aussi montré que les portées incorporées peuvent être utiles pour localiser du trafic de réparation de diffusion groupée [8].

Deux barrières rendent actuellement la limitation administrative de portée difficile à déployer et utiliser :

o	Les applications n'ont aucun moyen de découvrir de façon dynamique les informations sur les portées qui sont pertinentes pour elles. Cela rend difficile l'utilisation des zones de portée administrative, et réduit donc l'incitation à les déployer.

o	Les mauvaises configurations sont faciles. Il est difficile de détecter les zones de portée qui ont été configurées de façon à n'être pas convexe (le plus court chemin entre deux nœuds au sein de la zone passe en-dehors de la zone), ou n'avoir pas de fuites (un ou plusieurs routeurs frontière n'ont pas été configurés correctement), ou qui se coupent à la fois dans la zone et dans la gamme d'adresses.

Ces deux barrières sont traités par le présent document. Il définit, en particulier, le protocole d'annonce de zone de portée de diffusion groupée (MZAP, Multicast Scope Zone Announcement Protocol) qui permet à une entité d'apprendre dans quelles zones de portée elle se trouve. Les serveurs vont normalement mettre en antémémoire les informations apprises de MZAP et peuvent alors fournir ces informations aux applications à la demande en utilisant d'autres moyens, par exemple, via MADCAP [9]. MZAP fournit aussi des informations de diagnostic aux routeurs frontière eux-mêmes qui leur permettent de détecter les zones de portée mal configurées.

2.	Terminologie

La "portée locale" est définie dans la RFC 2365 [1] et représente la plus petite portée administrative supérieure à la liaison locale, et la gamme d'adresses associée est définie comme 239.255.0.0 à 239.255.255.255 inclus (pour IPv4, FF03::/16 pour IPv6). La RFC 2365 spécifie :

"239.255.0.0/16 est défini comme étant la portée locale IPv4. La portée locale est la portée minimale, et n'est pas divisible. Bien que l'extension exacte d'une portée locale dépende du site, les régions de portée locale doivent obéir à certaines contraintes topologiques. En particulier, une portée locale ne doit pas s'étendre au delà des frontières d'une autre portée. De plus, une portée locale doit être entièrement contenue au sein de toute portée supérieure ou égale. Dans le cas où les régions de portée se chevauchent dans la zone, la zone de chevauchement doit être dans sa propre portée locale. Cela implique que toute frontière de portée soit aussi une frontière pour la portée locale".

Un routeur frontière de zone de portée de diffusion groupée (ZBR) est un routeur qui est configuré avec une frontière pour une portée de diffusion groupée particulière sur une ou plusieurs de ses interfaces. Toute interface qui est configurée avec une frontière pour toute zone de portée administrative DOIT aussi avoir une frontière pour la zone de portée locale, comme décrit ci-dessus.

De tels routeurs DEVRAIENT être configurés de telle sorte que le routeur lui-même soit à l'intérieur de la zone de portée. Ceci est montré à la Figure 1(a), où le routeur A est à l'intérieur de la zone de portée et a la configuration de frontière.

          ............                     ................
         .            .   +B+-->          .                *B+-->
        .              . /               .                / .
       .                *               .                +   .
       .          <---+A*---+C+->       .          <---+A+---*C+->
       .              + .               .              +     .
       .             /  .               .             /      .
        . zone X  <--  .                 . zone X  <--      .
         ..............                   ..................

A,B,C - routeurs    * - interface de frontière   + - interface
(a)  zone frontière correcte        (b) zone frontière incorrecte

Figure 1 : Placement de frontière de zone de portée administrative

Il est possible au premier routeur en dehors de la zone de portée d'être configuré avec la frontière, comme illustré à la Figure 1(b) où les routeurs B et C sont en-dehors de la zone et ont la configuration de frontière, tandis que A ne l'a pas, mais ceci N'EST PAS RECOMMANDÉ. Cette règle ne s'applique pas pour les frontières de portée locale, mais s'applique pour tous les autres routeurs frontière.

Nous définissons ensuite le terme de "identifiant de zone" pour désigner la plus petite adresse IP utilisée par tout ZBR pour une zone particulière pour générer des messages MZAP dans cette zone de portée. La combinaison de cette adresse IP et de la première adresse de diffusion groupée dans la gamme de la portée sert à identifier de façon univoque la zone de portée. Chaque ZBR écoute les messages provenant des autres ZBR sur la même frontière, et peut déterminer l'identifiant de zone sur la base des adresses de source vues. L'identifiant de zone peut changer avec le temps à mesure que les ZBR s'activent et se désactivent.

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

Les constantes utilisées par ce protocole sont données dans [NAME-OF-CONSTANT], et résumées à la section 7.

3.	Généralités

Lorsque un ZBR est configuré correctement, il peut déduire quel côté de la frontière est à l'intérieur de la zone de portée et quel côté est à l'extérieur.

Un tel ZBR envoie alors des messages d'annonce de zone (ZAM, Zone Announcement Message) périodiques pour chaque zone pour laquelle il est configuré comme frontière dans cette zone de portée, qui contiennent des informations sur la gamme d'adresses de la zone de portée, l'identifiant de zone, et les noms textuels. Ces messages sont envoyés en diffusion groupée aux adresses bien connues [MZAP-LOCAL-GROUP] dans la portée locale, et sont relayés à travers les frontières de portée locale dans toutes les zones de portée locale au sein de la zone de portée visée par le message ZAM, comme indiqué à la Figure 2.

    ###########################
    # Zone1      =      Zone2 #    ##### = frontière de zone de grande portée
    *E-----+--->A*-----+-x    #
    #      |     =     v      #    ===== = frontières de zones locales
    #      |     ======*===*==#
    #      |     =     B   F  #    ----> = chemin du ZAM généré par E
   G*<-----+--->C*->   |   ^  #
    #      v     =   <-+---+  #    ABCDE = ZBR
    #      D     =      Zone3 #
    #######*###################        * = interface de frontière

Figure 2 : Exemple d'arrosage de ZAM

Toute entité peut donc écouter sur un seul groupe d'adresses bien connues et apprendre toutes les portées dans lesquelles elle réside.

3.1	Incorporation de portée

MZAP permet aussi de découvrir les relations d'incorporation entre les zones de portée. Deux zones sont incorporées si l'une est comprise dans un sous ensemble des routeurs de l'autre, comme le montre la Figure 3.

     +-----------+       +-----------+      +-------------+
     | Zone 1    |       | Zone 3    |      | Zone 5      |
     |   +------+|       |    +------+      |    .........|..
     |   |Zone 2||       |    |Zone 4|      |    : Zone 6 | :
     |   +--A---+|       |    C      |      |    D        | :
     +-----------+       +----+--B---+      +--------E----+ :
            (a)               (b)           (c)  :..........:

(a) "Contenue" La zone 2 est incorporée dans la zone 1
(b) "Frontière commune"  La zone 4 est incorporée dans la zone 3
(c) "Chevauchement" Les zones 5 et 6 ne sont pas incorporées

Figure 3 : Exemples de zones incorporées

Un ZBR ne peut pas déterminer de façon indépendante si une zone est incorporée à une autre. Cependant, il peut déterminer qu'une zone N'EST PAS incorporée dans une autre. Par exemple, dans la Figure 3 :

o	Le ZBR A va passer des ZAM pour la zone 1 mais va empêcher les ZAM provenant de la zone 2 de quitter la zone 2. Lorsque le ZBR A reçoit en premier un ZAM pour la zone 1, il peut alors savoir que la zone 1 n'est pas incorporée dans la zone 2, mais il ne peut cependant pas déterminer si la zone 2 est incorporée dans la zone 1.

o	Le ZBR B agit comme ZBR pour les deux zones 3 et 4, et donc ne peut pas déterminer si l'une est incorporée dans l'autre. Cependant, le ZBR C peut déterminer que la zone 3 n'est pas incorporée dans la zone 4 lorsque il reçoit un ZAM pour la zone 3, car c'est un ZBR pour la zone 4 mais pas pour la 3.

o	Le ZBR D n'agit comme ZBR que pour la zone 6 et pas pour la zone 5, donc le ZBR D peut déduire que la zone 5 n'est pas incorporée dans la zone 6 en entendant un ZAM pour la zone 5. De même, le ZBR E agit seulement comme ZBR de zone 5 et pas de la 6, donc le ZBR E peut en déduire que la zone 6 n'est pas incorporée dans la zone 5 en entendant un ZAM pour la zone 6.

Le fait que les ZBR puissent déterminer qu'une zone n'est pas incorporée dans une autre, mais pas qu'une zone est bien incorporée dans une autre, signifie que l'incorporation doit être déterminé de façon répartie. Cela se fait en envoyant des messages "Pas-dedans" (NIM, Not-Inside Message) qui expriment le fait qu'une zone X n'est pas à l'intérieur d'une zone Y. De tels messages sont envoyés au [MZAP-LOCAL-GROUP] bien connu et sont donc vus par toutes les entités qui écoutent les messages ZAM (par exemple, les serveurs MADCAP). De telles entités peuvent alors déterminer les relations d'incorporation entre deux portées sur la base de l'absence soutenue de la preuve contraire.

3.2	Autres messages

Deux autres types de message, les messages de convexité de zone (ZCM, Zone Convexity Message) et les messages Limite de zone dépassée (ZLE, Zone Limit Exceeded) ne sont utilisés que par les routeurs, et leur permettent de comparer leurs configurations pour assurer la cohérence et détecter les malformations. Ces messages sont envoyés à l'adresse relative MZAP au sein de la gamme de portée associée à la zone de portée à laquelle elle se réfère, et ils ne sont donc normalement pas vus par les entités autres que les routeurs. Leur utilisation pour la détection de scénarios spécifiques de malformations sera traité dans la section suivante.

Les formats des paquets pour tous les messages sont décrits à la Section 5.

3.3	Identifiants de zone

Lorsque un routeur frontière démarre, il utilise sa plus basse adresse IP qu'il considère comme étant à l'intérieur d'une zone donnée, et qui est acheminable partout au sein de la zone (par exemple, pas une adresse de liaison locale) comme identifiant de zone pour cette zone. Il programme alors des messages ZCM (et ZAM) à envoyer à l'avenir (il ne les envoie pas immédiatement). Lorsque un ZCM est reçu pour la portée en question, l'envoyeur est ajouté à la liste locale des ZBR (y compris lui-même) pour cette portée, et l'identifiant de zone est mis à jour à la plus faible adresse IP dans la liste. Les entrées de la liste arrivent finalement à expiration si aucun autre message ultérieur n'est reçu de ce ZBR, de sorte que cet identifiant de zone va converger vers la plus basse adresse de tout ZBR actif sur cette portée.

Noter que l'envoyeur des messages ZAM NE DOIT PAS être utilisé de cette façon parce que la procédure pour détecter une fuite sur une portée locale décrite au paragraphe 4.3 ci-dessous repose sur deux zones disjointes pour la même gamme de portée avec un identifiant de zone différent. Si les ZAM sont utilisés pour calculer l'identifiant de zone, les fuites de ZAM à travers la frontière d'une portée locale vont alors causer la convergence des deux zones vers le même identifiant de zone.

4.	Détection de mauvaise configuration de routeur

Dans cette section, on traite de la détection  des diverses conditions d'erreur. Si une erreur est détectée, le routeur devrait essayer d'alerter un administrateur du réseau sur la nature de la malformation. Les moyens de le faire sortent du domaine d'application de MZAP.

4.1	Détection de zones de portée non convexes

Les messages de convexité de zone (ZCM, Zone Convexity Message) sont utilisés par les routeurs pour détecter les zones de portée administrative non convexes, qui sont une malformation possible. Les zones de portée non convexes peuvent causer des problèmes aux applications car un receveur ne peut jamais voir des paquets à portée administrativement limitée provenant d'un envoyeur au sein de la même zone de portée, dans la mesure où les paquets qui voyagent entre elles peuvent être refoulés à la frontière.

Dans l'exemple illustré par la Figure 4, le chemin entre B et D sort de la portée (à travers A et E). Ici, le routeur B et le routeur C envoient des ZCM au sein d'une zone de portée données pour laquelle ils ont chacun une frontière, et chacun faisant rapport aux autres  routeurs frontière sur la zone d'où ils écoutent. Dans la Figure 4, le routeur D ne peut pas voir les messages du routeur B, mais il peut voir les rapports de C sur B, et peut ainsi conclure que la zone n'est pas convexe.

    #####*####========
    #    B   #       =         ##### = frontière de portée non convexe
    #    |->A*       =
    #    |   #       =         ===== = autres frontières de portée
    #    |   ####*####
    #    |       E   #         ----> = chemin des ZCM de B
    #    v          D*
    #    C           #             * = interface de frontière
    #####*############

Figure 4 : Détection de non convexité

Les zones de portée non convexes peuvent être détectées par trois méthodes :

(1)	Si un ZBR figure sur la liste dans les ZCM reçus, mais si l'interface de prochain bond (selon le RIB de diffusion groupée) vers ce ZBR est en dehors de la zone de portée.

(2)	Si un ZBR figure sur la liste dans les ZCM reçus, mais si aucun ZCM n'est reçu de ce ZBR pendant [ZCM-HOLDTIME] secondes, comme illustré à la Figure 4.

(3)	Les messages ZAM peuvent aussi être utilisés d'une manière similaire à celle des ZCM en (1) ci-dessus, comme suit : si un ZAM est reçu d'un ZBR sur une interface interne à une zone de portée donnée, et si l'interface de prochain bond (selon le RIB de diffusion groupée) vers ce ZBR est en dehors de la zone de portée.

Les messages de convexité de zone PEUVENT  aussi être envoyés et reçus par des hôtes ordinaires correctement configurés au sein d'une région de portée, ce qui peut être une utile facilité de diagnostic qui n'exige pas d'accès privilégié.

4.2	Détection de fuite dans des frontières de portées non locales

Une frontière "à fuite" est celle qui a un "trou" logique du fait qu'un routeur n'a pas une frontière appliquée à une interface où il devrait en exister une. Et donc, la frontière n'entoure pas complètement une partie du réseau, d'où il résulte que des données à portée limitée s'échappent au dehors.

Les frontières de portée à fuite peuvent être détectées par deux méthodes :

(1)	Si il reçoit des ZAM générés à l'intérieur de la frontière de portée sur une interface qui pointe en dehors de la frontière de zone. Un tel message ZAM a dû s'échapper de la zone par une fuite, et il s'écoule en retour de derrière la frontière. Ceci est illustré à la Figure 5.

        =============#####*########
        = Zone1      #    A Zone2 #       C   = routeur mal configuré
        =      +---->*E   v       #
        =      |     #    B       #     ##### = frontière de portée percée
        =======*=====#====*=======#
        =      D     #    |       #     ===== = autres frontières de portée
        =      ^-----*C<--+       #
        = Zone4      #      Zone3 #     ----> = chemin des ZAM
        =============##############

Figure 5 : Fuite de ZAM

(2)	Si un message Limite de zone dépassée (ZLE) est reçu. Le paquet ZAM contient aussi une Limite des zones parcourues (Zones Traveled Limit). Si le nombre de zones de portée locale traversées devient égal à la limite des zones parcourues, un message ZLE est généré (le mécanisme de suppression pour empêcher l'implosion est décrit plus loin au paragraphe sur les Règles de traitement). Les ZLE détectent les fuites lorsque les paquets ne retournent pas dans une autre partie de la même zone de portée, mais atteignent d'autres zones de portée locale loin de l'origine du ZAM.

Dans l'un et l'autre cas, le routeur mal configuré sera soit l'origine du message, soit un des routeurs de la liste des chemins du ZBR qui est incluse dans le message reçu (ou peut-être un routeur sur le chemin entre deux de ces ZBR qui pourrait avoir été un ZBR lui-même).

4.3	Détection d'une fuite sur une zone de portée locale
Une portée locale a une fuite si un routeur a une frontière de portée administrative sur une interface, mais n'a pas de frontière de portée locale sur cette interface comme spécifié dans la RFC 2365. Cela peut être détecté par la méthode suivante :
o	Si un ZAM pour une portée donnée est reçu par un ZBR qui est frontière pour cette portée, celui-ci compare l'identifiant de zone de portée de l'origine du ZAM avec son propre identifiant de zone pour la portée en question. Si les deux ne correspondent pas, c'est la preuve d'une malformation. Comme une discordance temporaire peut résulter immédiatement après un récent changement de l'accessibilité du ZBR de plus faible adresse, la malformation ne devrait être supposée que si la discordance est persistante.

La localisation exacte du problème peut être découverte en faisant un mtrace [5] à partir du routeur qui détecte le problème, en direction de l'origine du ZAM, pour tout groupe dans la gamme d'adresses identifiée par le ZAM. Le routeur en faute sera celui qui dit dans un rapport qu'une frontière a été atteinte.

4.4	Détection de conflit de zone de portée
Les gammes d'adresse en conflit peuvent être détectées par la méthode suivante :
o	Si un ZBR reçoit un ZAM pour une portée donnée, et si les adresses de début et de fin incluses se chevauchent, sans être identiques, avec les adresses de début et de fin d'une portée configurée localement.

Les conflits de noms de portées peuvent être détectés par la méthode suivante :
o	Si un ZBR est configuré avec un nom textuel pour une portée et un langage donnés, et si il reçoit un ZAM ou ZCM avec un nom pour les mêmes portée et langage, mais les noms des portées ne correspondent pas

La détection de l'un ou l'autre des types de conflit ci-dessus indique une mauvaise configuration du routeur local ou du routeur d'origine du message. Les outils de configuration DEVRAIENT retirer les espaces en tête et en queue de chaque nom pour éviter les malformations accidentelles.

5.	Format des paquets

Tous les messages MZAP sont envoyés sur UDP, avec un accès de destination de [MZAP-PORT] et un TTL IPv4 ou une limite de bonds IPv6 de 255.

Lors de l'envoi d'un message MZAP qui se réfère à une zone de portée donnée, un ZBR DOIT utiliser une adresse de source qui aura une signification partout dans la zone de portée à laquelle le message se réfère. Par exemple, les adresses de liaison locales NE DOIVENT PAS être utilisées.

L'en-tête de message MZAP courant (qui suit l'en-tête UDP), est comme indiqué ci-dessous :

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |B|    PTYPE    |Famille d'adr. |  NameCount    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Origine du message                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Adresse de l'identifiant de zone        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Adresse de début de zone                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Adresse de fin de zone                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Nom de zone codé-1 (longueur variable)              |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |     . . .                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  . . .        | Nom de zone codé-N (longueur variable)        |
   +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |   Bourrage (si nécessaire)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version : La version définie dans ce document est "version 0".

bit B ("Big", grande portée) :
S'il est mis à zéro, cela indique que la gamme des adresses dans la portée n'est pas subdivisable, et que les attributeurs d'adresses peuvent utiliser la gamme entière. Si il est à un, les attributeurs d'adresse ne devraient pas utiliser la gamme entière, mais devraient apprendre une sous gamme appropriée via un autre mécanisme (par exemple, AAP [7]).

Type de paquet (PTYPE) :
Les types de paquet définis dans ce document sont :
0	Message d'annonce de zone (ZAM)	
1	Limite de zone dépassée (ZLE)	
2	Message de convexité de zone (ZCM)	
3	Message Pas-dedans (NIM)	

Famille d'adresse :
C'est le numéro de famille d'adresse alloué par l'IANA [10,11] qui identifie la famille d'adresses pour toutes les adresses du paquet. Les familles définies pour IP sont :
1	IPv4	
2	IPv6	

NameCount : Nombre de blocs de nom de zone codés dans ce paquet. Le compte peut être zéro.

Origine du message : 32 bits (IPv4) ou 128 bits (IPv6)
Cela donne l'adresse IP de l'interface qui a généré le message.

Adresse d'identifiant de zone : 32 bits (IPv4) ou 128 bits (IPv6)
Cela donne la plus faible adresse IP d'un routeur frontière qui a été observée dans la zone d'origine du message. Avec les champs Adresse de début de zone et Adresse de fin de zone, il forme un identifiant unique pour la zone. Noter que cet identifiant est habituellement différent de l'identifiant de la zone de portée locale dans laquelle réside l'origine.

Adresse de début de zone : 32 bits (IPv4) ou128 bits (IPv6)
Ce champ donne l'adresse de début pour la frontière de zone de portée. Par exemple, si la zone est une frontière pour 239.1.0.0 à 239.1.0.255, l'adresse de début de zone est alors 239.1.0.0.

Adresse de fin de zone : 32 bits (IPv4) ou 128 bits (IPv6)
Ce champ donne l'adresse de fin pour la frontière de zone de portée. Par exemple, si la zone est une frontière pour 239.1.0.0 à 239.1.0.255, l'adresse de fin de zone est alors 239.1.0.255.

   Nom de zone codé :
      +--------------------+
      |D| Réservé  (7 bits)|
      +--------------------+
      | LangLong (1 octet) |
      +--------------------+-----------+
      | EtiqLangue (taille variable)   |
      +--------------------+-----------+
      | NomLong (1 octet)  |
      +--------------------+-----------+
      | Nom de zone (taille variable)  |
      +--------------------------------+

Le premier octet contient des fanions, dont seul le bit de poids fort est défini. Les autres bits sont réservés (envoyés à 0, ignorés à réception).

bit "D" pour langage par Défaut : Mis à 1, il indique la préférence pour l'utilisation du nom dans la langue suivante si aucun nom n'est disponible dans un langage désiré.

Longueur de l'étiquette de langue (LangLong) : 1 octet
C'est la longueur, en octets, de l'étiquette de langue.

EtiqLangue  (taille variable) : C'est l'étiquette de langue, telle que dans "en-US" (pour l'anglais des USA), qui indique le langage du nom de zone. Les étiquettes de langage sont décrites dans [6].

NomLong : C'est la longueur, en octets du champ Nom de zone. La longueur NE DOIT PAS être zéro.

Nom de zone : multiple de 8 bits
Le nom de zone est une chaîne de caractères ISO 10646 codée en UTF-8 [4] qui indique le nom donné à la zone de portée (par exemple, "Site Ouest d'ISI"). Il devrait rester relativement court et DOIT être inférieur à 256 octets. Les espaces DEVRAIENT être supprimées au début et à la fin de chaque nom avant de la coder, pour éviter les conflits accidentels.

Bourrage (si nécessaire) :
La fin de l'en-tête MZAP est bourrée d'octets à zéro jusqu'au verrouillage sur une limite de quatre octets.

5.1	Message d'annonce de zone

Un message d'annonce de zone a un PTYPE=0, et il est envoyé périodiquement par un ZBR pour chaque portée pour laquelle il est une frontière, SAUF :
o	pour la portée locale
o	pour la portée de liaison locale

Le format du message d'annonce de zone est indiqué ci-dessous.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        En-tête MZAP
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      ZT       |     ZTL       |         Temps de garde        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Adresse 0 d'identifiant de zone locale          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Adresse du routeur 1                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Adresse 1 d'identifiant de zone locale          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                .....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Adresse du routeur N                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Adresse N d'identifiant de zone locale          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Les champs sont définis comme suit :

Zones traversées (ZT) : 8 bits
Cela donne le nombre d'identifiants de zone locale contenus dans ce chemin de message.

Limite des zones traversées (ZTL) : 8 bits
Cela donne la limite du nombre de zones locales que le paquet peut traverser avant qu'on DOIVE l'abandonner. Une valeur de 0 indique qu'il n'y a pas de limite.

Temps de garde :
C'est la durée, en secondes, après laquelle le receveur devrait supposer que la portée n'existe plus, si aucun autre ZAM n'est reçu. Elle devrait être réglée à [ZAM-HOLDTIME].

Chemin de zone : multiple de 64 bits (IPv4) ou 256 bits (IPv6)
Le chemin de zone est une liste d'adresses d'identifiants de zone locale (l'adresse d'identifiant de zone d'une zone locale) à travers lesquelles le ZAM est passé, et des adresses IP du routeur qui a transmis le paquet. Le routeur d'origine remplit le champ "Adresse 0 d'identifiant de zone locale" lors de l'envoi du ZAM. Chaque routeur de portée locale qui transmet le ZAM à travers une frontière de portée locale DOIT ajouter l'adresse d'identifiant de zone locale de la zone locale dans laquelle le message est transmis, et sa propre adresse IP à la fin de cette liste, et incrémenter ZT en conséquence. Le chemin de zone est vide au début de l'envoi du ZAM.

5.2	Limite de zone dépassée (ZLE)

Le format d'un message ZLE est indiqué ci-dessous :
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             En-tête MZAP 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      ZT       |     ZTL       |        Temps de garde         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Adresse 0 d'identifiant de zone locale     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Adresse de routeur 1                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Adresse 1 d'identifiant de zone locale     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                .....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Adresse de routeur N                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Adresse d'identifiant de zone locale N          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Tous les champs sont copiés du ZAM, sauf le PTYPE qui est mis à un.

5.3	Message de convexité de zone

Un message d'annonce de zone a son PTYPE=2, et il est envoyé périodiquement par un ZBR pour chaque portée pour laquelle il est une frontière (sauf pour la portée de liaison locale). Noter que les ZCM SONT envoyés dans la portée locale.

À la différence des messages d'annonce de zone qui sont envoyés au [MZAP-LOCAL-GROUP], les messages de convexité de zone sont envoyés au [ZCM-RELATIVE-GROUP] dans la zone de portée elle-même. Le format d'un ZCM est indiqué ci-dessous.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              En-tête MZAP 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     ZNUM      | non utilisé   |          Temps de garde       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Adresse 1 de ZBR                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                .....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Adresse N de ZBR                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Les champs sont comme suit :

ZNUM (nombre d'adresses de ZBR) : 8 bits
Ce champ donne le nombre des adresses de ZBR contenues dans ce message.

Temps de garde :
C'est le temps, en secondes, après lequel le receveur devrait supposer que l'envoyeur n'est plus joignable, si aucun ZCM suivant n'est reçu. Il devrait être réglé à [ZCM-HOLDTIME].

Adresse de ZBR : 32 bits (IPv4) ou 128 bits (IPv6)
Ces champs donnent les adresses des autres ZBR d'où le ZBR d'origine du message a reçu les ZCM mais dont le temps de garde n'est pas arrivé à expiration. Le routeur devrait inclure toutes les adresses qui tiennent dans le paquet, en préférant celles qu'il n'avait pas incluses récemment si toutes ne tiennent pas.

5.4	Message Pas-dedans
Un message Pas-dedans (NIM, Not-Inside Message) a un PTYPE=3, et il est envoyé périodiquement par un ZBR qui sait qu'une portée X n'est pas incorporée au sein d'une autre portée Y ("X pas dedans Y"):

Le format d'un Message Pas-dedans est indiqué ci-dessous :

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               En-tête MZAP 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Adresse de début de la zone Pas-dedans          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Les champs sont comme suit :

En-tête MZAP : Ce sont les champs d'en-tête qui identifient la portée X. Le compte de nom peut être 0.

Adresse de début de la zone Pas-dedans : 32 bits (IPv4) ou 128 bits (IPv6). Cela donne l'adresse de début pour la portée Y.

6.	Règles de traitement des messages
6.1	Entités internes qui écoutent les messages MZAP

Tout hôte ou application peut se joindre au [MZAP-LOCAL-GROUP] pour écouter les messages d'annonce de zone pour construire une liste des zones de portée qui sont localement pertinentes, et les messages Pas-dedans si il souhaite apprendre les informations d'incorporation. Cependant, l'écoute de tels messages n'est pas la méthode recommandée aux applications régulières pour découvrir ces informations. Ces applications vont normalement interroger un serveur d'allocation d'adresses de diffusion groupées (MAAS, Multicast Address Allocation Server) locales [3], qui à son tour écoute les messages d'annonce de zone et les messages Pas-dedans pour entretenir les informations de portée, et qui peut être interrogé par les clients via les messages MADCAP.

Une entité (y compris un MAAS) qui n'a pas accès à ces informations peut seulement supposer qu'il est dans une portée mondiale et dans la portée locale, qui ont toutes deux des gammes d'adresses bien connues définies en [1].
Une entité interne (par exemple, un MAAS) qui reçoit un ZAM va analyser les informations qui sont pertinentes pour elle, telles que la gamme d'adresse, et les noms. Un allocateur d'adresses qui reçoit de telles informations DOIT aussi utiliser le bit "B" pour déterminer si il peut ajouter la gamme d'adresses à l'ensemble des gammes à partir desquelles il peut allouer des adresses (en particulier, il ne peut les ajouter que si le bit est à zéro). Même si le bit est à zéro, un MAAS DEVRAIT quand même mémoriser les informations de gamme afin que les clients qui utilisent des adresses relatives puissent toujours obtenir les gammes en les demandant au MAAS.

Une entité interne (par exemple, un MAAS) devrait supposer que X est incorporé dans Y si :
a)	il entend d'abord des ZAM de X et de Y il y a au moins [NIM-HOLDTIME] secondes, ET
b)	il n'a pas entendu de NIM indiquant que "X n'est pas dans Y" depuis au moins [NIM-HOLDTIME] secondes.
6.2	Envoi de ZAM
Chaque ZBR devrait envoyer un message d'annonce de zone pour chaque zone de portée pour laquelle il est une frontière toutes les [ZAM-INTERVAL] secondes, +/- 30 % de [ZAM-INTERVAL] à chaque fois, pour éviter la synchronisation de message.

Le paquet ZAM contient aussi une Limite des zones traversées (ZTL). Si le nombre d'identifiants de zone locale dans le chemin de ZAM devient égal à la limite des zones parcourues, le paquet sera abandonné. Le champ ZTL est établi quand le paquet est envoyé et prend par défaut la valeur de 32, mais il peut être établi à une valeur inférieure si l'administrateur du réseau connaît la taille attendue de la zone.
6.3	Réception de ZAM
Lorsque un ZBR reçoit un ZAM pour une zone de portée X, il utilise les règles suivantes.

Si le ZBR local n'a aucune configuration pour la portée X :

(1)	Vérifier si les adresses incluses de début et de fin se chevauchent, sans y être identiques, avec les adresses de début et de fin de toute portée Y de configuration locale, et si c'est le cas, signaler un conflit de gamme d'adresses à un administrateur local.

(2)	Créer une entrée d'état local "X pas dedans", si une telle entrée n'existe pas déjà. Le ZBR relance alors le temporisateur de l'entrée à [ZAM-HOLDTIME]. L'existence de cet état indique que le ZBR sait que X n'est pas incorporé dans une portée quelconque pour laquelle il est une frontière. Si le temporisateur de l'entrée arrive à expiration (parce qu'on entend plus de ZAM pour X depuis [ZAM-HOLDTIME]) l'entrée est supprimée.

Si le ZBR local a la configuration pour la portée X :

(1)	 Si le ZAM généré à l'EXTÉRIEUR de la portée (c'est à dire, reçu sur une interface frontière de la portée X) :
a)	Si l'identifiant de zone de portée dans le ZAM correspond au propre identifiant de zone de portée du ZBR, signaler alors une malformation de fuite de portée.
b)	Abandonner le ZAM (n'effectuer aucun des traitements ci-dessous). Par exemple, le routeur G de la Figure 2 ne transmettra pas le ZAM. Cette règle est principalement une mesure de sûreté, car le placement de G dans la Figure 2 n'est pas une configuration recommandée, comme exposé plus haut.

2)	Si le ZAM a été généré à l'INTÉRIEUR de la portée :
a)	Si l'interface de prochain bond (conformément au RIB de diffusion groupée) vers l'origine est en dehors de la zone de portée, signaler alors un problème de non convexité.
b)	Si l'identifiant de zone de portée d'origine dans le ZAM ne correspond pas à l'identifiant de zone de portée conservé par le ZBR local, et si cette discordance continue de se produire, signaler alors un avertissement de fuite de portée possible.
c)	Pour chaque nom textuel dans le ZAM, voir si un nom pour la même portée et le même langage est configuré localement ; s'il en est ainsi, mais si les noms de portée ne correspondent pas, signaler un conflit de noms de portée à un administrateur local.
d)	Si le ZAM a été reçu sur une interface qui N'EST PAS une frontière de portée locale, et si la dernière adresse d'identifiant de zone locale sur la liste des chemins est 0, le ZBR remplit l'adresse d'identifiant de zone locale de la zone locale d'où le ZAM a été reçu.

Si un ZAM pour la même portée (comme identifié par l'identifiant de zone d'origine et la première adresse de diffusion groupée) a été reçu dans les [ZAM-DUP-TIME] dernières secondes, le ZAM est alors éliminé. Autrement, le ZAM est mis en antémémoire pour au moins [ZAM-DUP-TIME] secondes. Par exemple, lorsque le routeur C de la Figure 2 reçoit le ZAM via B, il ne sera pas transmis, car il vient juste de transmettre le ZAM provenant de E.

Le compte de zones parcourues est alors incrémenté dans le message, et si le compte mis à jour est égal ou supérieur au champ ZTL, il programme l'envoi d'un ZLE comme décrit au paragraphe suivant et n'effectue plus aucun des traitements ci-dessous.

Si l'identifiant de zone de la zone de portée locale dans laquelle réside le ZBR n'est pas déjà dans la liste des chemins du ZAM, celui-ci est alors immédiatement regénéré au sein de la zone de portée locale. Avant de le faire, il ajoute à la liste des chemins du ZAM sa propre adresse et l'identifiant de zone de la zone de portée locale dans laquelle le message est transmis. Un ZBR qui reçoit un ZAM avec une liste de chemins non nulle NE DOIT PAS retransmettre ce ZAM dans une zone de portée locale qui est contenue dans sa liste des chemins. Par exemple, à la Figure 2, le routeur F, qui n'a pas obtenu le ZAM via A du fait d'une perte de paquet, ne va pas transmettre le ZAM provenant de B en retour dans la Zone 2 car la liste des chemins a { (E,1), (A,2), (B,3) } et donc la Zone 2 apparaît déjà.

De plus, le ZBR regénère le ZAM sur chaque interface avec une frontière de portée locale (sauf qu'il ne le renvoie par l'interface sur laquelle il a été reçu, ni ne l'envoie dans aucune zone de portée locale dont l'identifiant est connu et apparaît dans la liste des chemins). Dans chacun de tels ZAM régénérés, le ZBR ajoute sa propre adresse IP à la liste des chemins, ainsi que l'adresse d'identifiant de zone de la zone de portée locale dans laquelle le ZAM est envoyée, ou 0 si l'identifiant est inconnu. (Par exemple, si l'autre extrémité d'une liaison en point à point a aussi une frontière sur l'interface, la liaison n'a alors pas d'identifiant de zone de portée locale.)
6.4	Envoi des ZLE
Ce paquet est envoyé par un routeur frontière de zone locale qui aurait excédé la limite de zones parcourues si il avait transmis un paquet ZAM. Pour éviter une implosion de ZLE, ceux-ci sont envoyés en diffusion groupée avec un délai aléatoire et supprimés par les autres ZLE. Il n'est programmé que si au moins [ZLE- MIN-INTERVAL] secondes se sont écoulées depuis le précédent envoi d'un ZLE à une destination quelconque. Pour programmer un ZLE, le routeur établit un temporisateur aléatoire de retard dans l'intervalle [ZLE-SUPPRESSION-INTERVAL], et écoute le [MZAP-RELATIVE-GROUP] au sein de la portée incluse pour les autres ZLE. S'il en est qui soient reçus avant l'arrivée à expiration du temporisateur aléatoire de retard, le temporisateur est éliminé et le ZLE n'est pas envoyé. Si le temporisateur arrive à expiration, le routeur envoie un ZLE au [MZAP-RELATIVE-GROUP] au sein de la portée indiquée.

La méthode utilisée pour choisir un retard aléatoire (T) est la suivante :

Choisir une valeur aléatoire X dans l'intervalle uniforme aléatoire [0:1]
Soit C = 256
Établir T = [ZLE-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C)

Cette équation résulte en une distribution exponentielle aléatoire qui assure que le ZBR proche de un va répondre. Utiliser une distribution purement uniforme commencerait à poser des problèmes d'échelle lorsque le nombre de ZBR augmente. Comme les ZLE ne sont supprimés que si un ZLE dupliqué arrive avant la fin de temporisation choisie, deux routeurs qui choisissent des délais qui diffèrent d'une quantité inférieure au délai de propagation entre eux vont tous deux envoyer des messages, consommant inutilement de la bande passante. Il est donc souhaitable de minimiser le nombre de routeurs qui choisissent un retard proche du plus faible délai choisi, et une distribution exponentielle convient pour cela.

Un routeur NE DEVRAIT PAS envoyer plus d'un message Limite de zone dépassée toutes les [ZLE-MIN-INTERVAL] secondes, sans considération de la destination.

6.5	Réception des ZLE

Lorsque un routeur reçoit un ZLE, il effectue les actions suivantes :

(1)	Si le routeur a programmé l'envoi d'un message ZLE, il déprogramme l'envoi de son propre message afin qu'un autre ne soit pas envoyé.

(2)	Si le ZLE contient la propre adresse du routeur dans le champ Origine, il signale une malformation de fuite de portée.

6.6	Envoi des ZCM

Chaque ZBR devrait envoyer un Message de convexité de zone (ZCM) pour chaque zone de portée pour laquelle il est une frontière toutes les [ZCM-INTERVAL] secondes, +/- 30 % de [ZCM-INTERVAL] chaque fois, pour éviter une synchronisation de message.

Les ZCM sont envoyés au [ZCM-RELATIVE-GROUP] dans la gamme de portée limitée elle-même. (Par exemple, si la gamme de portée est de 239.1.0.0 à 239.1.0.255, ces  messages devraient alors être envoyés à 239.1.0.252.) Comme ce ne sont pas des paquets à portée locale, ils sont simplement envoyés en diffusion groupée à travers la zone de portée elle-même, et ne requièrent pas de construction de chemin, ni de traitement particulier par les ZBR de portée locale intermédiaires.
6.7	Réception des ZCM

Lorsque un ZCM est reçu pour une portée X donnée, sur une interface qui est à l'intérieur de la portée, elle doit respecter les règles suivantes :

(1)	L'origine est ajoutée à la liste locale des ZBR (y compris lui-même) pour cette portée, et l'identifiant de zone est mis à jour comme étant la plus basse adresse IP de la liste. La nouvelle entrée est programmée pour arriver en fin de temporisation après [ZCM-HOLDTIME] si aucun message ultérieur n'est reçu de ce ZBR, afin que l'identifiant de zone converge vers la plus basse adresse de tout ZBR actif pour cette portée.

(2)	Si un ZBR figure dans la liste des ZCM reçus, mais si l'interface de prochain bond (selon le RIB de diffusion groupée) vers ce ZBR est en dehors de la zone de portée, ou si aucun ZCM n'est reçu de ce ZBR pendant [ZCM-HOLDTIME] secondes, comme dans l'exemple de la Figure 4, elle signale alors un problème de non convexité.

(3)	Pour chaque nom textuel dans le ZCM, voir si un nom est configuré localement pour la même portée et le même langage ; si il en est un, mais si les noms de portée ne correspondent pas, signaler un conflit de nom de portée à l'administrateur local.

6.8	Envoi des NIM

Périodiquement, pour chaque zone de portée Y pour laquelle il est une frontière, un routeur génère un message Pas-dedans (NIM, Not-Inside Message) pour chaque entrée "X pas dedans" qu'il a créée à réception des ZAM. Comme un ZAM, ce message est envoyé en diffusion groupée à l'adresse [MZAP-LOCAL-GROUP] d'une de ses interfaces intérieure à Y.

Chaque ZBR devrait envoyer un tel message Pas-dedans toutes les [NIM-INTERVAL] secondes, +/- 30 % de [NIM-INTERVAL] pour éviter de synchroniser les messages.

6.9	Réception des NIM

Lorsque un ZBR reçoit un NIM qui dit que "X n'est pas dans Y", il est transmis, non modifié, d'une manière similaire à celle des ZAM :

(1)	Si le NIM a été reçu sur une interface avec une frontière avec X ou Y, le NIM est éliminé.

(2)	À la différence des ZAM, si le NIM n'a pas été reçu sur l'interface tournée vers l'origine du message (selon le RIB de diffusion groupée), le NIM est éliminé.

(3)	Si un NIM pour les mêmes X et Y (où chacun est identifié par sa première adresse de diffusion groupée) a été reçu dans les dernières [ZAM-DUP-TIME] secondes, le NIM n'est pas transmis.

(4)	Autrement, le NIM est mis en antémémoire pendant au moins [ZAM-DUP-TIME] secondes.

(5)	Le ZBR regénère alors le NIM (c'est-à-dire, avec la charge utile UDP d'origine) dans chaque zone de portée locale dans laquelle il a des interfaces, sauf qu'il n'est pas renvoyé dans la zone de portée locale d'où le message a été reçu, ni à aucune interface qui a une frontière avec X ou Y.

7.	Constantes

[MZAP-PORT] : C'est l'accès UDP bien connu auquel tous les messages MZAP sont envoyés. Valeur : 2106.

[MZAP-LOCAL-GROUP] : C'est dans la portée locale le groupe bien connu auquel sont envoyés les ZAM. Tous les serveurs d'allocation d'adresse de diffusion groupée et les routeurs frontière de zone écoutent ce groupe. Valeur : 239.255.255.252 pour IPv4.

[ZCM-RELATIVE-GROUP] : C'est le groupe relatif dans chaque zone de portée, auquel sont envoyés les ZCM. Un routeur frontière de zone écoute ce groupe relatif dans chaque portée pour laquelle il est une frontière. Valeur : (dernière adresse IP dans la gamme de portée) - 3. Par exemple, dans la portée locale, le groupe relatif est le même que l'adresse [MZAP-LOCAL-GROUP].

[ZAM-INTERVAL] : C'est l'intervalle auquel un routeur frontière de zone génère les messages d'annonce de zone. La valeur par défaut est de 600 secondes (10 minutes).

[ZAM-HOLDTIME] : C'est le temps de garde à inclure dans un ZAM. Il DEVRAIT être réglé au moins à 3 * [ZAM-INTERVAL]. La valeur par défaut est de 1 860 secondes (31 minutes).

[ZAM-DUP-TIME] : C'est l'intervalle de temps après l'émission d'un ZAM, durant lequel les ZAM pour la même portée ne seront pas émis. La valeur par défaut est de 30 secondes.

[ZCM-INTERVAL] : C'est l'intervalle auquel un routeur frontière de zone génère les messages de convexité de zone. La valeur par défaut est de 600 secondes (10 minutes).

[ZCM-HOLDTIME] : C'est le temps de garde à inclure dans un ZCM. Il DEVRAIT être réglé au moins à 3 * [ZCM-INTERVAL]. La valeur par défaut est de 1860 secondes (31 minutes).

[ZLE-SUPPRESSION-INTERVAL] : C'est l'intervalle sur lequel choisir un délai aléatoire avant d'envoyer un message ZLE. La valeur par défaut est de 300 secondes (5 minutes).

[ZLE-MIN-INTERVAL] : C'est l'intervalle minimum entre l'envoi des messages ZLE, sans considération de la destination. La valeur par défaut est de 300 secondes (5 minutes).

[NIM-INTERVAL] :  C'est l'intervalle auquel un routeur frontière de zone génère les messages Pas-dedans. La valeur par défaut est de 1800 secondes (30 minutes).

[NIM-HOLDTIME] : C'est le temps de garde à inclure dan l'état au sein d'un NIM. Il DEVRAIT être réglé au moins à 3 * [NIM-INTERVAL]. La valeur par défaut est de 5460 secondes (91 minutes).

8.	Considérations pour la sécurité

Bien que la lecture non autorisée des messages MZAP soit relativement inoffensive (de sorte que le chiffrement n'est généralement pas une solution) l'acceptation de messages MZAP non authentifiés peut poser des problèmes. L'authentification des messages MZAP peut être fournie par l'utilisation de l'en-tête d'authentification IPsec (AH) [12].

Dans le cas des ZCM et des ZLE, un attaquant peut causer des problèmes de fausses connexion de convexité et de fuites. Il est vraisemblable que ce serait une simple gène et que ce ne causerait aucun problème significatif. (De tels messages pourraient être authentifiés, mais comme ils peuvent être envoyés dans de grandes portées, le receveur pourrait n'être pas capable d'authentifier un envoyeur non malintentionné.)

Les ZAM et les NIM, d'un autre côté, sont envoyés au sein de la portée locale, où on suppose qu'une relation de sécurité entre envoyeurs et receveurs est plus praticable.

Dans le cas des NIM, accepter des messages non authentifiés peut causer la fausse annulation de relations d'incorporation. Cela serait cause de l'aplatissement d'une section de la hiérarchie des zones. Un tel aplatissement diminuerait le bénéfice de l'efficacité apportée par la hiérarchie mais ne la rendrait pas inutilisable.

Accepter des messages ZAM non authentifiés pourrait cependant être cause que les applications croient qu'une zone de portée existe alors que ce n'est pas le cas. Si ils devaient être crus, les applications pourraient choisir d'utiliser ces portées administratives non existantes pour leurs besoins. De telles applications seraient capables de communiquer, mais ne pourraient savoir si leur trafic peut être acheminé plus loin que ce à quoi elles s'attendent. Il en résulte que toute application qui accepte des ZAM non authentifiés DOIT seulement prendre les noms de portée comme une indication, et DEVRAIT supposer que leur trafic envoyé à des zones de portée locale peut voyager n'importe où. La confidentialité d'un tel trafic NE PEUT PAS être tenue pour acquise du fait qu'elle a été envoyée sur une adresse à portée limitée qui a été découverte en utilisant MZAP.

De plus, les ZAM sont utilisés pour informer les serveurs d'allocation d'adresses de diffusion groupée (MAAS) des noms et des gammes d'adresse des portées, et accepter des ZAM non authentifiés pourrait résulter en la présentation de faux noms aux utilisateurs, et à l'allocation de mauvaises adresses aux usagers. Pour contrer cela, les MAAS authentifient les ZAM comme suit :

(1)	Un ZBR signe tous les ZAM qu'il génère (en utilisant un AH).

(2)	Un ZBR signe un ZAM qu'il relaie si et seulement si il peut authentifier l'envoyeur précédent. Un ZBR DOIT encore transmettre des ZAM non authentifiés (pour assurer la détection de fuites), mais devrait propager un ZAM authentifié même si un non authentifié a été reçu dans les dernières [ZAM-DUP-TIME] secondes.

(3)	Un MAAS DEVRAIT être configuré avec la clé publique de la zone locale dans laquelle il réside. Un MAAS ainsi configuré DEVRAIT ignorer un ZAM non authentifié si un ZAM authentifié pour la même portée a été reçu, et PEUT ignorer tous les ZAM non authentifiés.

9.	Remerciements

Le présent document a été produit par le groupe de travail "MBone Deployment", dont les membres ont fourni de nombreux commentaires et suggestions utiles. Van Jacobson a fourni certaines des idées d'origine qui ont conduit à ce protocole. Le groupe de travail Allocation d'adresse en diffusion groupée a également fourni des retours utiles concernant les noms des portées et les interactions avec les applications.

10.	Références
(Les liens hypertexte pointent sur la version française lorsqu'elle existe, et sinon sur le texte anglais d'origine)
[1]	D. Meyer, "Diffusion groupée sur IP limitée administrativement", RFC 2365, BCP 23, juillet 1998..

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

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

[4]	F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", RFC 2279, janvier 1998. (Obsolète, voir RFC3629) (D.S.).

[5]	Fenner, W. and S. Casner, "A `traceroute' facility for IP Multicast", Travail en cours.

[6]	H. Alvestrand, "Étiquettes pour l'identification des langues", RFC 1766, mars 1995. (Obsolète, voir RFC3066, RFC3282) (P.S.).

[7]	Handley, M. and S. Hanna.  "Multicast Address Allocation Protocol (AAP)", Travail en cours.

[8]	Kermode, R. "Scoped Hybrid Automatic Repeat reQuest with Forward Error Correction (SHARQFEC)", ACM SIGCOMM 98, September 1998, Vancouver, Canada.

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

[10]	J. Reynolds et J. Postel, "Numéros alloués", RFC 1700, STD 2, octobre 1994. (Historique).

[11]	IANA, "Address Family Numbers", http://www.isi.edu/in-notes/iana/assignments/address-family-numbers

[12]	S. Kent et R. Atkinson, "En-tête d'authentification IP", RFC 2402, novembre 1998. (Obsolète, voir RFC4302, RFC4305) (P.S.).

11.	Adresse des auteurs

Mark Handley	David Thaler	Roger Kermode	
AT&T Center for Internet Research at ICSI	Microsoft	Motorola Australian Research Centre	
1947 Center St, Suite 600	One Microsoft Way	12 Lord St,	
Berkely, CA 94704	Redmond, WA 98052	Botany, NSW 2019	
USA	USA	Australia	
mél : mjh@aciri.org 	mél : dthaler@microsoft.com 	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 les besoins du développement des normes de l'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 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.