Groupe de travail Réseau

D. Meyer

Request for Comments 2365

University of Oregon

BCP : 23

juillet 1998

Catégorie : Bonnes pratiques actuelles

Traduction Claude brière de L'Isle

 

 

Diffusion groupée sur IP limitée administrativement

 

Statut de ce mémoire

Le présent document spécifie les bommes pratiques actuelles de l'Internet pour la communauté de l'Internet, et appelle à discussion et suggestions pour son amélioration. La distribution du présent mémoire n'est soumise à aucune restriction.

 

Notice de copyright

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

 

1.   Résumé

Le présent document définit "l'espace de diffusion groupée IPv4 limitée administrativement " comme étant dans la gamme 239.0.0.0 à 239.255.255.255. De plus, il décrit un ensemble sémantique simple pour la mise en œuvre de la diffusion groupée limitée administrativement. Enfin, il fournit une transposition entre les classes d'adresses IPv6 de diffusion groupée [RFC1884] et les classes d'adresse IPv4 de diffusion groupée.

 

Le présent mémoire a été produit par le groupe de travail Développement du MBONE (MBONED) dans le domaine Fonctionnement et gestion de l'Équipe d'ingénierie de l'Internet (IETF). Envoyez vos commentaires à <mboned@ns.uoregon.edu> ou à l'auteur.

 

2.   Remerciements

 

Beaucoup du présent mémoire est tiré de "Administratively Scoped IP Multicast" que Van Jacobson et Steve Deering ont présenté à la 30 ème réunion de l'IETF, Toronto, Canada, le 25 juillet 1994. Steve Casner, Mark Handley et Dave Thaler ont aussi fourni de remarquables commentaires sur les versions antérieures de ce document.

 

3.   Introduction

 

La plupart des mises en œuvre de diffusion groupée IP réalisent un certain niveau de limitation de portée en utilisant le champ Durée de vie (TTL, Time To Live) de l'en-tête IP. L'utilisation typique du MBONE (cœur de réseau de diffusion groupée) a été d'imaginer des seuils de TTL qui confinent le trafic à certaines régions topologiques définies administrativement. La règle de base de la transmission pour les interfaces avec des seuils de TTL configurés est qu'un paquet n'est pas transmis à travers l'interface si son TTL restant n'est pas supérieur au seuil.

 

La limitation du TTL a été utilisée pour contrôler la distribution du trafic de diffusion groupée avec l'objectif d'alléger la pression sur des ressources rares (par exemple, la bande passante) ou de réaliser une certaine forme de confidentialité améliorée ou de propriétés d'échelonnement. De plus, le TTL est aussi utilisé dans son rôle traditionnel pour limiter la durée de vie des datagrammes. Étant donné que ces rôles entrent souvent en conflit, la limitation du TTL s'est révélée difficile à mettre en œuvre de façon fiable, et les schémas résultants ont souvent été complexes et difficiles à comprendre.

 

Un problème architectural plus sérieux concerne l'interaction de la limitation du TTL avec les protocoles de diffusion et d'élagage (par exemple, DVMRP [DVMRP]). Le problème particulier est que dans de nombreux cas courants, la limitation du TTL peut empêcher l'efficacité de l'élagage. Considérons le cas dans lequel un paquet a son TTL qui est arrivé à expiration ou a échoué à un seuil de TTL. Le routeur qui élimine le paquet ne sera pas capable d'élaguer les sources vers l'amont, et va donc collecter tout le trafic de diffusion groupée (qu'il y ait ou non des receveurs en aval). Noter qu'alors qu'il pourrait sembler possible d'envoyer des ordres d'élagage vers l'amont du point auquel un paquet est éliminé, cette stratégie peut déboucher sur l'élimination de trafic légitime, car les paquets suivants pourraient prendre un chemin différent et arriver au même point avec un TTL supérieur.

 

D'un autre côté, la diffusion groupée IP limitée administrativement peut fournit une sémantique claire et simple à la diffusion groupée IP limitée. Les propriétés clés de la diffusion groupée IP limitée administrativement sont que :

(i)   les paquets destinés à des adresses de diffusion groupée limitée administrativement ne traversent pas les frontières administrative configurées, et

(ii)   les adresses de diffusion groupée limitées administrativement sont allouées localement, et donc n'ont pas l'exigence d'unicité à travers les frontières administratives.

 

4.   Définition de l'espace de diffusion groupée IPv4 limitée administrativement

 

L'espace d'adresses de diffusion groupée IPv4 limitée administrativement est défini comme étant la gamme 239.0.0.0 à 239.255.255.255.

 

5.   Discussion

Afin de prendre en charge la diffusion groupée IP limitée administrativement, un routeur devrait prendre en charge la configuration de frontières de diffusion groupée IP limitée interface par interface. Un tel routeur, appelé un routeur frontière, ne transmet les paquets qui correspondent à la définition de frontière d'une interface dans aucune des deux directions (la vérification bidirectionnelle empêche les problèmes avec les réseaux multi accès). De plus, un routeur frontière élague toujours la frontière pour les groupes en mode dense [PIMDM], et n'accepte pas les adjonctions pour les groupes en mode épars [PIMSM] dans la gamme de la limitation administrative.

 

6.   Structure de l'espace de diffusion groupée limitée administrativement

La structure de l'espace de diffusion groupée IP version 4 limitée administrativement est fondée de façon lâche sur l'architecture d'adressage de IP version 6 décrite dans la [RFC1884]. Le présent document définit deux portées importantes : la portée locale IPv4 et la portée locale d'organisation IPv4. Ces portées sont décrites ci-dessous.

 

6.1   Portée locale IPv4 -- 239.255.0.0/16

239.255.0.0/16 est définie comme étant la portée locale IPv4. La portée locale est la portée minimale d'enveloppe, et n'est donc pas divisible. Bien que l'extension exacte d'une portée locale dépende du site, les régions à 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'autres portées. De plus, une portée locale doit être entièrement contenue au sein de toute portée égale ou plus grande. Dans le cas où le domaine d'une portées recoupe une autre portée dans une zone, la zone de chevauchement doit être dans sa propre portée locale. Cela implique que toute frontière de portée est aussi une frontière pour la portée locale. Les exigences topologiques plus générales des régions limitées administrativement sont exposées ci-dessous.

 

6.1.1   Expansion de la portée locale IPv4

L'espace de portée locale IPv4 croît "de haut en bas". À ce titre, la portée locale IPv4 peut croître de haut en bas de 239.255.0.0/16 jusqu'aux gammes réservées 239.254.0.0/16 et 239.253.0.0/16. Cependant, ces gammes ne devraient pas être utilisées jusqu'à ce que l'espace 239.255.0.0/16 ne soit plus suffisant.  

6.2   Portée locale d'organisation IPv4 -- 239.192.0.0/14

239.192.0.0/14 est définie comme étant la portée locale d'organisation IPv4, et c'est l'espace à partir duquel une organisation devrait allouer des sous gammes lorsque elle définit des portées pour une utilisation privée.

 

6.2.1   Expansion de la portée locale d'organisation IPv4

Les gammes 239.0.0.0/10, 239.64.0.0/10 et 239.128.0.0/10 ne sont pas allouées et sont disponibles pour l'expansion de cet espace. Ces gammes devraient être laissées non allouées jusqu'à ce que l'espace 239.192.0.0/14 ne soit plus suffisant. Cela laisse aussi la possibilité que de futures révisions du présent document définissent des portées additionnelles sur une échelle plus large que les organisations.

 

6.3   Autres portées IPv4 intéressantes

Les deux autres classes de portée intéressantes, portée de liaison locale allouée de façon statique et portée mondiale, existent déjà dans l'espace de diffusion groupée IPv4.

 

La portée de liaison locale allouée de façon statique est 224.0.0.0/24. Les allocations existantes de portée mondiale statique sont un peu plus ciblées et incluent :

224.1.0.0-224.1.255.255           groupes ST de diffusion groupée

224.2.0.0-224.2.127.253           appels de conférence multimédia

224.2.127.254                           annonces SAPv1

224.2.127.255                           annonces SAPv0 (déconseillé)

224.2.128.0-224.2.255.255       allocations dynamiques SAP

224.252.0.0-224.255.255.255   groupes transitoires DIS

232.0.0.0-232.255.255.255       groupes transitoires VMTP

 

Voir dans la [RFC1700] les allocations actuelles d'adresse de diffusion groupée (cette liste se trouve aussi, éventuellement sous une forme plus actuelle à ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses).

 

7.   Exigences topologiques pour les frontières administratives

 

Une région de diffusion groupée IP limitée administrativement est définie comme une région topologique dans laquelle il y a un ou plusieurs routeurs frontière avec des définitions de frontière communes. Un tel routeur est dit être une frontière pour les adresses limitées dans la gamme définie dans sa configuration.

 

Les administrateurs de réseaux peuvent configurer une région de portée chaque fois qu'une portée de diffusion groupée restreinte est nécessaire. De plus, un administrateur peut configurer des régions de portée en chevauchement (les réseaux peuvent être dans plusieurs régions de portée) lorsque cela leur convient, avec pour seule limitation qu'une région de portée doit être connectée (il doit y avoir un chemin qui ne quitte pas cette région entre deux nœuds quelconques au sein d'une région de portée) et convexe (c'est-à-dire, aucun chemin entre deux points quelconques de la région ne peut traverser une frontière de région). Cependant, il est important de noter que si des zones limitées administrativement se recoupent topologiquement, leur portée extérieure doit consister en son espace d'adresse moins les espaces d'adresse de toute portée intersécante. Cette exigence empêche les problèmes qui proviendraient du franchissement de la frontière d'une région intersécante par un chemin entre deux points dans une région convexe. Pour cette raison, il est recommandé que les portées administratives qui s'entrecoupent topologiquement ne se recoupent pas dans la gamme des adresses.

 

Noter enfin que toute frontière de portée est une frontière pour la portée locale. Cela implique que les paquets envoyés à des groupes couverts par 239.255.0.0/16 ne doivent pas être transmis à travers une liaison pour laquelle une frontière de portée est définie.

 

8.   Partition de l'espace de diffusion groupée limitée administrativement

 

Le tableau suivant résume le partage de l'espace de diffusion groupée IPv4, et donne la transposition des préfixes de diffusion groupée IPv4 en valeurs SCOP IPv6 :

 

SCOP IPv6

Description de la RFC 1884

Préfixe IPv4

0

réservé

 

1

portée de nœud local

 

2

portée de liaison locale

224.0.0.0/24

3

(non alloué)

239.255.0.0/16

4

(non alloué)

 

5

portée de site local

 

6

(non alloué)

 

7

(non alloué)

 

8

portée d'organisation locale

239.192.0.0/14

A

(non alloué)

 

B

(non alloué)

 

C

(non alloué)

 

D

(non alloué)

 

E

portée mondiale

224.0.1.0-238.255.255.255

F

réservé

 

 

(non alloué)

239.0.0.0/10

 

(non alloué)

239.64.0.0/10

 

(non alloué)

239.128.0.0/10

 

9.   Structure et utilisation d'une région de portée

 

Le /24 à droite dans toute région de portée est réservé aux allocations relatives. Une allocation relative est un décalage entier à partir de la plus haute adresse dans la portée et représente une adresse de 32 bits (pour IPv4). Par exemple, dans la portée locale définie plus haut, 239.255.255.0/24 est réservé aux allocations relatives. L'allocation relative de facto "0", (c'est-à-dire, 239.255.255.255 dans la portée locale) existe actuellement pour SAP [SAP]. L'allocation relative suivante, "1", correspond à l'adresse 239.255.255.254 dans la portée locale. Le reste d'une région de portée au delà du /24 réservé est disponible pour des allocations dynamiques (vraisemblablement par un protocole d'allocation d'adresse).

 

Il est important de noter qu'un protocole de découverte de portée [MZAP] devra être développé pour faire une utilisation pratique des portées autres que la portée locale. De plus, comme toute utilisation de région de portée limitée administrativement, y compris la portée locale, exige un adressage à allocation dynamique, un protocole d'allocation d'adresse (AAP, Address Allocation Protocol) devra être développé pour rendre la limitation administrative de portée d'utilisation générale.

 

9.1   Lignes directrices pour l'allocation relative

Les demandes d'allocations relatives devraient être envoyées à l'IANA. L'IANA sera conseillée par un expert du domaine pour faire les allocations d'adresses relatives. L'expert du domaine sera désigné par le directeur de zone pertinent.

 

En général, les adresses relatives ne seront utilisées que pour l'amorçage sur des allocations d'adresse dynamiques à l'intérieur de la portée. À ce titre, les allocations relatives ne devraient être accordées qu'aux services qui ne peuvent pas utiliser le protocole d'allocation dynamique d'adresse pour trouver l'adresse utilisée par ce service au sein de la portée désirée, comme un service d'allocation dynamique d'adresse lui-même.

 

10.   Considérations pour la sécurité

 

Il est recommandé que les organisations qui utilisent les adresses de diffusion groupée IP limitées administrativement ne s'appuient pas sur elles pour empêcher la transmission de leurs données sensibles hors de l'organisation. Si un routeur de diffusion groupée ou une frontière administrative est mal configuré, s'il y a une erreur dans le code de portée administrative, ou s'il y a un autre problème qui serait cause que le routeur transmette un paquet en diffusion groupée IP limitée administrativement en dehors de la portée appropriée, les données d'organisations quitteraient la région de transmission prévue.

 

Les organisations qui utilisent la diffusion groupée IP limitée administrativement pour transmettre des données sensibles devraient utiliser des mécanismes de confidentialité (par exemple, le chiffrement) pour protéger ces données. Dans le cas de nombreux sites existants d'applications de visioconférence le chiffrement est disponible comme caractéristique de l'application et doit simplement être activé (et les clés de chiffrement appropriées distribuées en toute sécurité). Pour de nombreuses autres applications, l'utilisation de la charge utile de sécurité par encapsulation (ESP, Encapsulating Security Payload) IP [RFC-1825, RFC-1827] peut fournir la confidentialité de la couche IP au moyen du chiffrement.

 

Dans le contexte d'un groupe de diffusion groupée IP limitée administrativement, l'utilisation de la distribution manuelle de clé peut être faisable. Alors que la gestion dynamique de clés pour la sécurité d'IP est un domaine de recherche au moment de la rédaction de la présente note, on s'attend à ce que l'IETF étende le protocole de gestion de clé ISAKMP pour la prise en charge à l'avenir d'une distribution modulable de clés de diffusion groupée.

 

Il est important de noter que le "routeur frontière" décrit dans la présente note ne fournit pas nécessairement de capacité de pare-feu.

 

11.   Références

 

[ASMA]   V. Jacobson, S. Deering, "Administratively Scoped IP Multicast", présenté au 30 e IETF, Toronto, Canada, 25 juillet 1994.

 

[DVMRP]   T. Pusateri, "Protocole d'acheminement en diffusion groupée par vecteur de distance", travail en cours.

 

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

 

[PIMDM]   S. Deering, et autres, "Diffusion groupée indépendante du protocole version 2 : Spécification du mode dense", RFC 3973, janvier 2005.

 

[PIMSM]   D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma et L. Wei, "Mode épars de diffusion groupée indépendante du protocole (PIM-SM) : Spécification du protocole", RFC 2362, juin 1998.

 

[RFC1700]   J. Reynolds et J. Postel, "Numéros alloués", STD 2, octobre 1994. (Historique, voir www.iana.org).

 

[RFC1884]   R. Hinden, S. Deering, éditeurs, "Architecture d'adressage d'IP version 6", décembre 1995. (Obsolète, voirRFC2373) (Historique)

 

[SAP]   M. Handley, "SAP : Protocole d'annonce de session", RFC 2974, octobre 2000. (Expérimentale)

 

12.   Adresse de l'auteur

 

David Meyer

Cisco Systems

San Jose, CA

mél : dmm@cisco.com

 

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

 

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

 

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

 

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

 

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et L'INTERNET SOCIETY ET L'INTERNET ENGINEERING TASK FORCE DÉCLINE TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER, TOUTE GARANTIE QUE L'UTILISATION DE L'INFORMATION ICI PRÉSENTE N'ENFREINDRA AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D'ADAPTATION A UN OBJET PARTICULIER.