4. Attribution et agrégation d'adresses
- Attribution et agrégation d'adresses
L'adressage et le routage classless ont été initialement développés principalement pour améliorer les propriétés d'évolutivité du routage sur l'Internet global.
Parce que l'évolutivité du routage est très étroitement couplée à la manière dont les adresses sont utilisées, le déploiement du CIDR a eu des implications sur la façon dont les adresses étaient attribuées.
4.1. Efficacité et limites de l'agrégation
La seule méthode communément comprise pour réduire l'état de routage sur un réseau à commutation de paquets est l'agrégation de l'information. Pour que le CIDR réussisse à réduire la taille et le taux de croissance du système de routage global, le processus d'attribution d'adresses IPv4 devait être modifié pour rendre possible l'agrégation des informations de routage le long des lignes topologiques. Étant donné que, en général, la topologie du réseau est déterminée par les fournisseurs de services qui l'ont construit, les attributions d'adresses topologiquement significatives sont nécessairement orientées vers les fournisseurs de services.
L'agrégation est simple pour un site terminal connecté à un seul fournisseur de services : il utilise l'espace d'adressage attribué par son fournisseur de services, et cet espace d'adressage est un petit morceau d'un bloc plus large alloué au fournisseur de services. Aucune route explicite n'est nécessaire pour le site terminal ; le fournisseur de services annonce une seule route agrégée pour le bloc plus large. Cette annonce fournit l'accessibilité et la routabilité pour tous les clients numérotés dans le bloc.
Il existe deux situations, plus complexes, qui réduisent l'efficacité de l'agrégation :
o Une organisation multi-hébergée (multi-homed). Parce qu'une organisation multi-hébergée doit être annoncée dans le système par chacun de ses fournisseurs de services, il n'est souvent pas envisageable d'agréger ses informations de routage dans l'espace d'adressage de l'un quelconque de ces fournisseurs. Notez que l'organisation peut toujours recevoir son attribution d'adresses à partir de l'espace d'adressage d'un fournisseur de services (ce qui présente d'autres avantages), mais qu'une route vers le préfixe de l'organisation est, dans le cas le plus général, annoncée explicitement par tous ses fournisseurs de services. Pour cette raison, le coût de routage global pour une organisation multi-hébergée est généralement le même qu'avant l'adoption du CIDR. Un examen plus détaillé des pratiques de multi-hébergement peut être trouvé dans [RFC4116].
o Une organisation qui change de fournisseur de services sans procéder à une renumérotation. Cela a pour effet de « percer un trou » dans l'une des annonces de routes agrégées du fournisseur de services d'origine. Le CIDR gère cette situation en exigeant que le fournisseur de services plus récent annonce une publicité spécifique pour l'organisation re-hébergée ; cette annonce est préférée aux agrégats du fournisseur car il s'agit d'une correspondance plus longue. Pour maintenir l'efficacité de l'agrégation, il est recommandé qu'une organisation qui change de fournisseur de services planifie éventuellement la migration de son réseau vers un préfixe attribué à partir de l'espace d'adressage de son nouveau fournisseur. À cette fin, il est recommandé que des mécanismes facilitant une telle migration, tels que l'attribution dynamique d'adresses d'hôtes utilisant [RFC2131], soient déployés partout où possible, et qu'un travail de protocole supplémentaire soit accompli pour développer une technologie améliorée de renumérotation.
Notez qu'un certain gain d'efficacité d'agrégation peut encore être obtenu pour les sites multi-hébergés (et, de manière générale, pour tout site composé de multiples réseaux IPv4 logiques) : en allouant un bloc contigu d'espace d'adressage de taille puissance de deux au site (plutôt que de multiples préfixes indépendants), les informations de routage du site peuvent être agrégées en un seul préfixe. De plus, étant donné que le coût de routage associé à l'attribution d'un site multi-hébergé à partir de l'espace d'adressage d'un fournisseur de services n'est pas supérieur à l'ancienne méthode d'attribution séquentielle de numéros par une autorité centrale, il est logique d'attribuer tout l'espace d'adressage des sites terminaux à partir de blocs alloués aux fournisseurs de services.
Il convient également de mentionner que, puisque l'agrégation peut se produire à plusieurs niveaux dans le système, il peut encore être possible d'agréger ces routes anormales à des niveaux supérieurs de toute hiérarchie présente. Par exemple, si un site est multi-hébergé sur deux fournisseurs relativement petits qui obtiennent tous deux leur connectivité et leur espace d'adressage auprès du même grand fournisseur, alors l'agrégation par le grand fournisseur des routes en provenance des réseaux plus petits inclura toutes les routes vers le site multi-hébergé. La faisabilité de ce type d'agrégation de second niveau dépend de l'existence d'une hiérarchie topologique entre un site, ses fournisseurs directement connectés, et les autres fournisseurs aux quels ils sont connectés ; cela peut être pratique dans certaines régions de l'Internet global mais pas dans d'autres.
Note : Dans la discussion et les exemples qui suivent, la notation de préfixe est utilisée pour représenter les destinations de routage. Cela est utilisé à des fins d'illustration uniquement et n'exige pas que les protocoles de routage utilisent cette représentation dans leurs mises à jour.
4.2. Attribution distribuée de l'espace d'adressage
Aux débuts de l'Internet, l'attribution de l'espace d'adressage IPv4 était effectuée par le centre d'information réseau (NIC) central. Les numéros de réseau de classe A/B/C étaient attribués dans un ordre essentiellement arbitraire, grossièrement selon la taille des organisations qui les demandaient. Toutes les attributions étaient enregistrées centralement, et aucune tentative n'était faite pour attribuer les numéros de réseau d'une manière qui aurait permis l'agrégation du routage.
Lors du déploiement initial du CIDR, l'autorité d'attribution centrale continua d'exister mais modifia ses procédures pour attribuer de grands blocs de numéros de réseau de « classe C » à chaque fournisseur de services. Chaque fournisseur de services, à son tour, attribuait des sous-ensembles orientés par masque de bits de l'espace d'adressage du fournisseur à chaque client. Cela fonctionna raisonnablement bien, tant que le nombre de fournisseurs de services était relativement petit et relativement constant, mais cela ne s'étendit pas bien, le nombre de fournisseurs de services croissant à un rythme rapide.
Alors que l'Internet commençait à s'étendre rapidement dans les années 1990, il devint clair qu'une autorité d'attribution d'adresses unique et centralisée posait problème. Cette fonction commença à être décentralisée lorsque l'attribution d'espace d'adressage pour les sites Internet européens fut déléguée en blocs alignés sur les bits de 16777216 adresses (ce que le CIDR définirait plus tard comme un /8) au RIPE NCC ([RIPE]), faisant effectivement de lui le premier des RIR. Depuis lors, l'attribution d'adresses a été formellement distribuée comme une fonction hiérarchique avec l'IANA, les RIR et les fournisseurs de services. Supprimer le goulot d'étranglement d'une organisation unique ayant la responsabilité de l'espace d'adressage de l'Internet global a grandement amélioré l'efficacité et le temps de réponse pour les nouvelles attributions.
La délégation hiérarchique d'adresses de cette manière implique que les sites dont les adresses sont attribuées à partir d'un fournisseur de services donné font, à des fins de routage, partie de ce fournisseur de services et seront routés via son infrastructure. Cela implique que les informations de routage concernant les organisations multi-hébergées (c'est-à-dire les organisations connectées à plus d'un fournisseur de services de réseau) devront toujours être connues par les niveaux supérieurs de la hiérarchie.
Une perspective historique sur ces questions est décrite dans [RFC1518]. Des discussions supplémentaires peuvent également être trouvées dans [RFC3221].