Architecture d'allocation d'adresse de diffusion groupée Internet

Statut de ce mémoire

Le présent mémoire apporte des informations à la communauté de l'Internet. Il ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright

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

Résumé

Le présent document propose une architecture d'allocation d'adresses de diffusion groupée (MALLOC) pour l'Internet. L'architecture est modulaire avec trois couches, comportant un mécanisme hôte-serveur, un mécanisme de coordination serveur- serveur intra domaine, et un mécanisme inter domaine.

Table des Matières

1.   Introduction

2.   Exigences

2.1   Address Dynamics

3.   Vue générale de l'architecture

4.   Scoping

4.1   Allocation Scope

5.   Généralités sur le processus d'allocation

6.   Considérations pour la sécurité

7.   Remerciements

8.   Références

9.   Adresse des auteurs

10.   Déclaration de droits de reproduction

1.   Introduction

Le présent document propose une architecture d'allocation d'adresse de diffusion groupée (MALLOC, multicast address allocation architecture) pour l'Internet, et il est destiné à être assez générique pour s'appliquer aussi bien aux environnements IPv4 que IPv6.

Comme avec les adresses d'envoi individuel, l'usage de toute adresse de diffusion groupée est limité dans deux dimensions :

Durée de vie :

Une adresse a une heure de début et une heure de fin (éventuellement infinie) entre lesquelles elle est valide.

Portée :

Une adresse est valide sur une zone spécifique du réseau. Par exemple, elle peut être valide et unique mondialement, ou elle peut être une adresse privée qui n'est valide que dans une zone locale.

2.   Exigences

Du point de vue de la conception, les propriétés importantes des mécanismes d'allocation d'adresse de diffusion groupée sont la robustesse, l'à propos, la faible probabilité de conflit d'attribution, et une bonne utilisation de l'espace d'adresse dans les situations où l'espace est rare. Lorsque cela interagit avec l'acheminement de diffusion groupée, il est souhaitable que les adresses de diffusion groupée soient allouées d'une manière qui aide à l'agrégation des états d'acheminement.

o   Robustesse/disponibilité

L'exigence de robustesse est qu'une application qui requiert l'allocation d'une adresse soit toujours capable d'en obtenir une, même en présence de défaillances du réseau.

o   À propos

Du point de vue de l'à propos, un court délai de quelques secondes avant que le client reçoive une adresse avec une confiance raisonnable en son unicité est probablement acceptable. Si la session est définie à l'avance, l'adresse devrait être allouée aussitôt que possible, et on ne devrait pas attendre le début de la session. Il est acceptable dans certains cas de changer les adresses de diffusion groupée utilisées par la session jusqu'au moment du début réel de la session, mais cela ne devrait être fait que lorsqu'on est averti d'un problème significatif tel qu'un conflit d'adresses qui n'est découvert qu'après la définition de la session initiale.

o   Faible probabilité de conflit

Un schéma d'allocation d'adresses de diffusion groupée devrait toujours être capable d'allouer une adresse dont il puisse être garanti qu'elle n'entre pas en conflit avec une autre session. Une partition descendante de l'espace d'adresse serait nécessaire pour garantir pleinement qu'aucun conflit ne surviendra.

o   Conservation de l'espace d'adresse dans les situations de rareté

Dans les situations où l'espace d'adresse est rare, la simple partition de l'espace d'adresse résulterait en une fragmentation significative de l'espace d'adresse. Et cela parce qu'on aurait besoin d'assez d'espace de réserve dans chaque partition de l'espace d'adresse pour donner un degré d'assurance raisonnable que les adresses pourraient encore être allouées pendant une durée significative dans l'éventualité d'une partition du réseau. De plus, fournir des serveurs d'allocation de sauvegarde dans une telle hiérarchie, afin que les défaillances (y compris le partitionnement d'un serveur et de sa sauvegarde) ne causent pas de collisions ajouterait encore à la fragmentation de l'espace d'adresse.

Dans la mesure où garantir de façon robuste l'absence de conflit exige une partition de l'espace d'adresse, fournir une forte garantie conduit à une utilisation inefficace de l'espace d'adresse. Et donc, lorsque l'espace d'adresses est rare, il est difficile de réaliser à la fois une disponibilité constante et l'à propos, de garantir l'absence de conflit ainsi qu'un bon usage de l'espace d'adresses. Il en résulte que l'on doit affecter des priorités à ces propriétés. Nous pensons que lorsque l'espace d'adresses est rare, réaliser une bonne conservation de l'espace d'adresse et une disponibilité constantes sont plus importants que de garantir qu'aucun conflit d'adresse ne va jamais survenir. Ce que l'on vise dans ces situations est une très forte probabilité que ne survienne pas de conflit d'adresses, mais on accepte qu'il y ait une probabilité finie que cela arrive. Si un conflit devait survenir (ou si une application devait commencer à utiliser une adresse qui ne lui est allouée, ce qui peut aussi conduire à un conflit) soit le conflit peut être détecté et les adresses changées, soit les hôtes qui reçoivent du trafic supplémentaire peuvent élaguer ce trafic en utilisant des élagueurs spécifiques de source disponibles dans IGMP version 3, et donc on ne pense pas que ce soit une situation désastreuse.

En résumé, tolérer la possibilité de conflits va vraisemblablement permettre l'allocation d'une très forte proportion de l'espace d'adresses en présence de conditions réseau telles que celles observées en [3].

Nous pensons qu'on peut avoir une bonne conservation et une bonne disponibilité avec un bon évitement de conflit, alors que nous avons à arbitrer de façon significative entre conservation et disponibilité pour éviter toute collision.

Finalement, dans les situations où l'espace d'adresses n'est pas rare, comme avec IPv6, réaliser une bonne utilisation de l'espace d'adresses est moins important, et donc des partitions peuvent éventuellement être utilisées pour garantir l'absence de collisions parmi les hôtes qui utilisent cette architecture.

2.1   Dynamique des adresses

Les adresses de diffusion groupée peuvent être allouées d'une des trois façons suivantes :

Statique :

L'allocation statique d'adresse est faite par l'IANA pour des protocole spécifiques qui exigent des adresses bien connues pour fonctionner. Des exemples d'adresses statiques sont 224.0.1.1 qui est utilisée pour le protocole de l'heure du réseau [13] et 224.2.127.255 qui est utilisée pour les annonces de session de diffusion groupée à portée mondiale. Les applications qui utilisent la diffusion groupée pour les besoins de l'amorçage ne devraient normalement pas recevoir une adresse de diffusion groupée statique propre, mais devraient s'amorcer eux-mêmes en utilisant une adresse bien connue de localisation de service qui puisse être utilisée pour annoncer le lien entre les services locaux et les adresses de diffusion groupée.

Les adresses statiques ont normalement une durée de vie permanente, et une portée définie par la gamme des portées dans laquelle elles résident. À ce titre, une adresse statique est valide partout (bien que l'ensemble des receveurs puisse être différent selon la localisation) et elle peut être incorporée dans les applications, appareils, systèmes internes, etc. Les adresses statiques sont aussi utiles pour les appareils qui prennent en charge l'envoi de datagrammes IP en diffusion groupée mais pas leur réception (conformité de niveau 1 spécifiée dans la RFC 1112 [7]), ou sont même incapables de recevoir aucunes données du tout, comme un appareil de diffusion sans fil.

Relative à la portée :

La RFC 2365 [1] réserve les 256 adresses les plus élevées de chaque gamme de portées administrative pour les allocations relatives. Les allocations relatives sont faites par l'IANA et consistent en un décalage qui est valide dans toutes les portées. Les adresses relatives sont réservées aux protocoles d'infrastructure qui exigent une adresse dans chaque portée, et ce décalage peut être incorporé dans les applications, appareils, systèmes embarqués, etc. De tels appareils doivent avoir un moyen (par exemple, via MZAP [9] ou via MADCAP [4]) d'obtenir la liste des portées sur lesquelles ils résident.

Les décalages alloués ont normalement une durée de vie permanente, et sont valides dans toute portée et localisation. Et donc, l'adresse relative à la portée dans une gamme de portées donnée a une durée de vie égale à celle de la gamme de portées dans laquelle elle tombe.

Dynamique :

Dans la plupart des cas, la façon correcte d'utiliser la diffusion groupée est d'obtenir une adresse de diffusion groupée dynamique. Ces adresses sont fournies à la demande et ont une durée de vie spécifique. Une application ne devrait demander une adresse que pour autant qu'elle s'attend à avoir besoin de l'adresse. Dans certaines circonstances, une adresse sera accordée pour une durée inférieure à celle qui était demandée. Cela arrivera rarement si la demande est faite pour une durée raisonnable. Les applications devraient être prêtes à s'en accommoder lorsque cela arrive.

À tout moment pendant la durée de vie d'une adresse existante, les applications peuvent aussi demander une extension de durée ce vie, et de telles extensions seront accordées lorsque c'est possible. Lorsque l'extension de l'adresse n'est pas accordée, l'application est censée demander une nouvelle adresse pour remplacer la vieille adresse arrivée à expiration, et être capable de faire face à cette situation en douceur. Comme avec les adresses d'envoi individuel, aucune garantie d'accessibilité d'une adresse n'est fournie par le réseau une fois la durée de vie achevée.

Ces restrictions sur la durée de vie de l'adresse sont nécessaires pour permettre d'organiser l'architecture d'allocation d'adresses autour de schémas d'utilisation des adresses qui assurent que les adresses sont agrégeables et que l'acheminement de diffusion groupée est raisonnablement proche de l'optimal. À l'opposé, les allocations statiques d'adresses peuvent recevoir un acheminement sous optimal.

3.   Vue générale de l'architecture

L'architecture est modulaire de sorte que chaque couche peut être utilisée, mise à niveau, ou remplacée de façon indépendante des autres. La mise en couches permet également l'isolement, en ce que différents mécanismes peuvent être utilisés à la même couche par différentes organisations sans impact néfaste sur les autres couches.

Cette architecture possède trois couches (Figure 1). Noter que ces numéros de couche sont différents de ceux de la pile TCP/IP qui décrivent le chemin des paquets de données.

Figure 1 : Vue d'ensemble de l'architecture d'allocation d'adresse de diffusion groupée

Couche 1

C'est un protocole ou un mécanisme qu'utilise un client de diffusion groupée pour demander une adresse de diffusion groupée à un serveur d'allocation d'adresses de diffusion groupée (MAAS, multicast address allocation server). Lorsque le serveur accorde une adresse, il est de sa responsabilité de s'assurer que cette adresse n'est pas réutilisée quelque part dans la portée de l'adresse pendant la durée de vie accordée.

Des exemples de protocoles ou mécanismes possibles à cette couche sont MADCAP [4], HTTP pour accéder à une page de la toile pour l'allocation, et l'IANA pour les allocations d'adresse statique.

Une API abstraite à utiliser pour l'allocation dynamique aux applications, indépendante du protocole/mécanisme de couche 1 utilisé, est donnée dans [11].

Couche 2

C'est un protocole ou mécanisme intra domaine qu'utilisent les MAAS pour coordonner les allocations pour s'assurer qu'ils n'allouent pas d'adresses dupliquées. Un MAAS doit avoir un moyen de mémorisation stable, ou quelque mécanisme de robustesse équivalente pour s'assurer que l'unicité est préservée à travers les défaillances et réamorçages du MAAS.

Les MAAS sont aussi utilisés par le protocole/mécanisme de couche 2 pour acquérir (auprès des "coordonnateurs de préfixes") les gammes d'adresses de diffusion groupée à partir desquelles ils peuvent allouer les adresses.

Dans le présent document on utilise le terme de "domaine d'allocation" pour désigner une région du réseau ayant la capacité de diffusion groupée et dont la portée est limitée administrativement, au sein de laquelle des adresses dans une gamme spécifique peuvent être allouées par un protocole/mécanisme de couche 2.

Parmi les exemples de protocoles ou mécanismes à cette couche on a AAP [5], et les configurations manuelles des MAAS.

Couche 3

Un protocole ou mécanisme inter domaine qui alloue des gammes d'adresses de diffusion groupée (avec une durée de vie) aux coordonnateurs de préfixes. Les adresses individuelles peuvent alors être allouées parmi ces gammes par les MAAS à l'intérieur des domaines d'allocation décrits ci-dessus.

Des exemples de protocoles ou mécanismes à cette couche sont MASC [6] (dans lequel les coordonnateurs de préfixes sont normalement des routeurs sans aucune exigence de capacité de mémorisation stable) et les allocations statiques par numéro d'AS décrits dans [10] (dans lesquelles les coordonnateurs de préfixes sont normalement des administrateurs humains).

Chacune de ces trois couches sert un objet légèrement différent et comme tels, les protocoles ou mécanismes à chaque couche peuvent exiger des équilibrages conceptuels différents.

4.   Limitation de portée

Pour une allocation dynamique des adresses au sein des portées administratives, un MAAS doit être capable d'apprendre quelles sont les portées en cours, quelles sont leurs gammes d'adresse et leurs noms, et quelles adresses ou sous gammes sont valides au sein de chaque portée pour l'allocation dynamique par le MAAS.

Les deux premières tâches, l'apprentissage des portées existantes et les gammes et noms d'adresse de chaque portée, peuvent être assurées par configuration statique ou par acquisition dynamique. Par exemple, un MAAS peut simplement écouter passivement les messages MZAP [9] pour acquérir cette information.

Pour déterminer la sous gamme pour l'allocation dynamique, il y a deux cas pour chaque portée, correspondants aux petites portées "indivisibles", et aux grosses portées "divisibles". Noter que MZAP identifie les portées qui sont divisibles et celles qui ne le sont pas.

(1)   Pour les petites portées, le domaine d'allocation correspond à la topologie entière au sein de la portée administrative. Et donc, tous les MAAS à l'intérieur de la portée peuvent utiliser la totalité de la gamme d'adresses (moins les 256 dernières adresses réservées comme adresses relatives de portée) et utiliser le mécanisme/protocole de couche 2 pour coordonner les allocations. Pour les petites portées, les coordonnateurs de préfixes ne sont pas impliqués.

   Et donc, pour les petites portées, la zone effective de "domaine d'allocation" peut être différente pour les différentes portées. Noter qu'une petite portée indivisible peut être plus grande ou plus petite que la portée d'allocation utilisée pour de grosses portées (voir ci-dessous).

(2)   Pour les grosses portées (y compris la portée mondiale) la zone à l'intérieur de la portée peut être assez grande pour que la simple utilisation d'un mécanisme/protocole de couche 2 soit inefficace ou autrement indésirable. Dans ce cas, la portée doit s'étendre sur plusieurs domaines d'allocation, et le mécanisme/protocole de couche 3 doit être utilisé pour diviser l'espace d'adresses entre les domaines d'allocation. Et donc, un MAAS peut apprendre la portée via MZAP, mais il doit acquérir auprès d'un coordinateur de préfixes une sous gamme à partir de laquelle faire les allocations.

Pour simplifier, la zone du "domaine d'allocation" effective sera la même pour toutes les grosses portées, car elle sera la granularité à laquelle toutes les grosses portées sont divisées. On définit la portée administrative à cette granularité comme étant la "portée d'allocation".

4.1   Portée d'allocation

La portée d'allocation est une nouvelle portée administrative, définie dans ce document et réservée par l'IANA avec les valeurs notées plus loin. C'est la portée qui est utilisée par un protocole/mécanisme de couche 2 pour coordonner l'allocation des adresses pour celles qui se trouvent dans de plus grandes portées divisibles.

Il est prévu que la portée d'allocation coïncide souvent avec une frontière de système autonome (AS) d'envoi individuel.

Si un AS est trop grand, ou si l'administrateur de réseau souhaite faire fonctionner des acheminements de diffusion groupée intra domaine différents dans les différentes parties d'un AS, cet AS peut être partagé par un réglage manuel d'une frontière de portée d'allocation qui ne soit pas une frontière d'AS. On fait cela en établissant une frontière de diffusion groupée qui divise l'AS d'envoi individuel en deux domaines d'allocation de diffusion groupée ou plus.

Si un AS est trop petit, et si l'espace d'adresses est rare, une fragmentation de l'espace d'adresses peut survenir si l'AS est son propre domaine d'allocation. Ici, l'AS peut autrement être traité comme faisant partie du domaine d'allocation de son fournisseur et utiliser un protocole/mécanisme de couche 2 pour coordonner les allocations entre son MAAS (s'il en est un) et son fournisseur. Un AS va probablement agir comme cela si :

o il est connecté à un seul fournisseur,

o il ne fournit pas de transit pour un autre AS, et

o il a besoin en moyenne de moins de (disons) 256 adresses de diffusion groupée de plus que la portée de l'AS allouée.

4.1.1   Portée d'allocation IPv4 -- 239.251.0.0/16

L'espace d'adresses 239.251.0.0/16 est à réserver pour la portée d'allocation. Les gammes 239.248.0.0/16, 239.249.0.0/16 et 239.250.0.0/16 sont à laisser sans allocation et disponibles pour l'expansion de cet espace. Ces gammes devraient être laissées sans allocation jusqu'à ce que l'espace 239.251.0.0/16 ne soit plus suffisant.

4.1.2   Portée d'allocation IPv6 -- SCOP 6

La valeur IPv6 "scop" est à utiliser pour la portée d'allocation.

5.   Généralités sur le processus d'allocation

Une fois que l'allocation de couche 3 a été effectuée pour les grandes portées divisibles, et que chaque coordonnateur de préfixe a acquis une ou plusieurs gammes, ces gammes sont alors passées à tous les MAAS dans le domaine du coordonnateur de préfixe via un mécanisme/protocole de couche 2.

Les MAAS au sein du domaine reçoivent ces gammes et les mémorisent comme les adresses actuellement allouables pour ce domaine. Chaque gamme est valide pour une durée de vie donnée (aussi acquise via le mécanisme/protocole de couche 3) et n'est pas révoquée avant l'arrivée à expiration de la durée de vie. Les MAAS apprennent aussi les petites portées (par exemple, via MZAP) et mémorisent les gammes qui leur sont associées.

En utilisant le mécanisme/protocole de couche 2, chaque MAAS s'assure qu'il va exclure toutes les adresses qui ont été ou seront allouées par les autres MAAS dans son domaine.

Lorsque un client a besoin d'une adresse de diffusion groupée, il a d'abord besoin de décider ce que devrait être la portée de la session prévue, et de localiser un MAAS capable d'allouer des adresses au sein de cette portée.

Pour choisir une portée, le client va soit simplement choisir une portée bien connue, comme la portée mondiale, soit énumérer les portées disponibles (par exemple, en envoyant une interrogation MADCAP, ou en écoutant les messages MZAP au fil du temps) et en permettant à l'utilisateur d'en choisir une.

La localisation d'un MAAS peut être faite via diverses méthodes, y compris la configuration manuelle, en utilisant un protocole de localisation de service comme SLP [12], ou via un mécanisme fourni par un protocole de couche 1 lui-même. MADCAP, par exemple, comporte une telle facilité.

Une fois que le client a choisi une portée et localisé un MAAS, il demande alors une adresse dans cette portée au MAAS localisé. Avec la demande, il envoie aussi la gamme acceptable pour les durées de vie de l'allocation qu'il désire. Par exemple, si le protocole de couche 1 utilisé est MADCAP, le client envoie un message MADCAP REQUEST au MAAS, et attend un message NAK ou un message ACK contenant les informations allouées.

À réception d'une demande d'un client, le MAAS choisit alors une adresse non utilisée dans une gamme pour la portée spécifiée, avec une durée de vie qui à la fois satisfasse la gamme acceptable spécifiée par le client, et soit dans la durée de vie de la gamme réelle.

Le MAAS utilise le mécanisme/protocole de couche 2 pour s'assurer qu'une telle adresse n'entre en conflit avec aucune adresse allouée par d'autres MAAS. Par exemple, si la couche 2 utilise une configuration manuelle de gammes qui ne se chevauchent pas, cela consiste simplement à adhérer à la gamme configurée dans le MAAS local. Si, d'un autre côté, AAP est utilisé à la couche 2 pour produire moins de fragmentation de l'espace d'adresses, le MAAS annonce sur l'ensemble du domaine l'allocation proposée à l'aide de AAP. Si aucune réclamation AAP pour conflit n'est reçue dans un intervalle de temps bref, l'adresse est retournée au client via le protocole/mécanisme de couche 1. Si une réclamation pour conflit est reçue par le MAAS, il va alors choisir une adresse différente et recommencer. AAP permet aussi à chaque MAAS de pré-réserver un petit "pool" d'adresses pour lesquelles il n'a pas besoin d'attendre que soient détectés des conflits.

Si un domaine commence à fonctionner en dehors des adresses de diffusion groupée disponibles, un coordonnateur de préfixe dans ce domaine utilisera le protocole/mécanisme de couche 3 pour acquérir plus d'espace.

6.   Considérations pour la sécurité

L'architecture décrite ici n'empêche pas une application d'envoyer simplement, ou de se joindre, à une adresse de diffusion groupée sans qu'elle lui soit allouée (tout comme c'est vrai aujourd'hui pour les adresses d'envoi individuel). Cependant, il n'est pas garanti que les données pour des adresses non allouées soient livrées par le réseau. C'est à dire que les routeurs peuvent abandonner les données pour des adresses non allouées si ils ont un moyen de vérifier si une adresse de destination a été allouée. Par exemple, si les routeurs frontière d'un domaine participent au protocole/mécanisme de couche 2 et mettent en antémémoire l'ensemble des adresses allouées, les données pour les adresses non allouées dans une gamme allouée par ce domaine peuvent alors être abandonnées par la création d'un état de transmission de diffusion groupée avec une liste d'interfaces de sortie vide et/ou en élaguant les branches de l'arborescence pour ces groupes.

Une application malveillante peut lancer une attaque de déni de service en tentant d'allouer un grand nombre d'adresses, essayant ainsi d'épuiser la fourniture des adresses disponibles. D'autres attaques incluent de libérer ou modifier l'allocation d'une autre partie. Ces attaques peuvent être combattues par l'utilisation de l'authentification avec des restrictions de politique (telles qu'un nombre maximum d'adresses pouvant être allouées à uns seule partie).

Et donc, les protocoles/mécanismes qui mettent en œuvre les couches de cette architecture devraient pouvoir être déployés d'une façon sécurisée. Par exemple, on devrait prendre en charge l'authentification avec des restrictions de politique, et on ne devrait pas permettre à des personnes non autorisées de libérer ou modifier l'allocation d'une autre partie.

7.   Remerciements

Steve Hanna a fourni des commentaires précieux sur ce document. Les membres du groupe de travail MALLOC et la communauté MBone ont apporté le soutien moral nécessaire à la réalisation de ce travail.

8.   Références

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

[2]   Mark Handley, "Multicast Session Directories and Address Allocation", Chapitre 6 de la thèse de doctorat intitulée "On Scalable Multimedia Conferencing Systems", University of London, 1997.

[3]   Mark Handley, "An Analysis of Mbone Performance", Chapitre 4 de la thèse de doctorat intitulée "On Scalable Multimedia Conferencing Systems", University of London, 1997.

[4]   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.)

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

[6]   P. Radoslavov et autres, "Protocole de revendication d'ensemble d'adresses de diffusion groupée (MASC)", RFC 2909, septembre 2000. (Expérimentale)

[7]   S. Deering, "Extensions d'hôte pour diffusion groupée sur IP", RFC 1112, STD 5, août 1989.

[8]   Y. Rekhter, T. Li , "Protocole de routeur frontière v. 4 (BGP-4)", RFC 1771, mars 1995. (Obsolète, voir RFC4271)

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

[10]   D. Meyer, P. Lothberg, "Adressage GLOP dans 233/8"), RFC 2770, février 2000. (Obsolète, voirRFC3180) (Exp.)

[11]   R. Finlayson, "API abstraite pour allocation d'adresse de diffusion groupée"), RFC 2771, février 2000. (Information)

[12]   E. Guttman et autres, "Protocole de localisation de service, version 2"), RFC 2608, juin 1999. (MàJ parRFC3224)

[13]   D. Mills, "Protocole de l'heure du réseau, version 3, spécification, mise en œuvre et analyse", RFC 1305, STD 12, mars 1992.

9.   Adresse des auteurs

10.   Déclaration de droits de reproduction

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

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.

Cette architecture suppose que le principal mécanisme de limitation de portée utilisé est une limitation administrative, comme décrit dans la RFC 2365 [1]. Bien que soient possibles des solutions qui fonctionnent pour la limitation du TTL, elles introduisent une complication supplémentaire significative pour l'allocation des adresses [2]. De plus, la limitation du TTL est une solution médiocre pour le contrôle de la portée en diffusion groupée, et notre hypothèse est que l'utilisation de la limitation par le TTL va dépérir avant que cette architecture ne soit largement utilisée.