3. L'adressage classless comme solution
- L'adressage classless comme solution
La solution créée par la communauté fut de déprécier le système d'attribution d'adresses de réseau de classe A/B/C au profit de l'utilisation de blocs hiérarchiques d'adresses IP « classless » (désignés sous le nom de préfixes). L'attribution de préfixes est destinée à suivre approximativement la topologie Internet sous-jacente afin que l'agrégation puisse être utilisée pour faciliter l'évolutivité du système de routage global. Une implication de cette stratégie est que l'attribution et l'agrégation de préfixes sont généralement effectuées selon les relations fournisseur-abonné, puisque c'est ainsi que la topologie Internet est déterminée.
Lorsqu'il fut proposé à l'origine dans [RFC1338] et [RFC1519], ce plan d'adressage était destiné à être une réponse relativement à court terme, d'une durée d'environ trois à cinq ans, pendant laquelle une architecture d'adressage et de routage plus permanente serait conçue et mise en œuvre. Comme peut le laisser supposer les dates des documents d'origine, le CIDR a largement dépassé sa durée de vie anticipée et est devenu la solution à moyen terme des problèmes décrits ci-dessus.
Notez que dans le texte qui suit, nous décrivons les politiques et procédures actuelles qui ont été mises en place pour mettre en œuvre l'architecture d'allocation discutée ici. Cette description n'est pas destinée à être interprétée comme une directive à l'IANA.
Couplée aux stratégies de gestion d'adresses mises en œuvre par les Registres Internet Régionaux (voir [NRO] pour les détails), le déploiement d'un adressage de style CIDR a également réduit le taux de consommation de l'espace d'adressage IPv4, fournissant ainsi un soulagement à court et moyen terme au problème n° 3 décrit ci-dessus.
Notez qu', ainsi que défini, ce plan n'exige ni ne suppose la réattribution des parties de l'ancien espace « classe C » qui ne se prêtent pas à l'agrégation (parfois appelé « the swamp » [le marécage]). Ce faire réduirait quelque peu la taille des tables de routage (l'estimation actuelle est que « the swamp » contient environ 15 000 entrées), mais au prix d'un coût de renumérotation important. De même, il n'y a pas d'exigence stricte qu'un site terminal quelconque renumérote lorsqu'il change de fournisseur de services de transit, mais les sites terminaux sont encouragés à le faire pour éliminer la nécessité d'une annonce explicite de leurs préfixes dans le système de routage global.
3.1. Concept de base et notation des préfixes
Dans le sens le plus simple, le passage des numéros de réseau de classe A/B/C aux préfixes classless consiste à rendre explicite quels bits dans une adresse IPv4 sur 32 bits sont interprétés comme le numéro de réseau (ou préfixe) associé à un site et lesquels sont utilisés pour numéroter les systèmes terminaux individuels au sein du site. Dans la notation CIDR, un préfixe est représenté sous la forme d'une quantité à 4 octets, tout comme une adresse IPv4 traditionnelle ou un numéro de réseau, suivie du caractère « / » (barre oblique), suivi d'une valeur décimale comprise entre 0 et 32 qui décrit le nombre de bits significatifs.
Par exemple, le réseau « classe B » d'origine 172.16.0.0, avec un masque de réseau implicite de 255.255.0.0, est défini comme le préfixe 172.16.0.0/16, le « /16 » indiquant que le masque permettant d'extraire la partie réseau du préfixe est une valeur sur 32 bits dont les 16 bits de poids fort sont des uns et les 16 bits de poids faible sont des zéros. De même, le numéro de réseau « classe C » d'origine 192.168.99.0 est défini comme le préfixe 192.168.99.0/24 ; les 24 bits de poids fort sont des uns et les 8 bits de poids faible sont des zéros.
L'utilisation de préfixes classless avec des longueurs de préfixe explicites permet une correspondance beaucoup plus flexible des blocs d'espace d'adressage selon les besoins réels. Là où autrefois seulement trois tailles de réseau étaient disponibles, des préfixes peuvent être définis pour décrire n'importe quel bloc de taille puissance de deux compris entre une et 2^32 adresses de systèmes terminaux. En pratique, le réservoir d'adresses non allouées est administré par l'Internet Assigned Numbers Authority ([IANA]). L'IANA effectue des allocations à partir de ce réservoir vers les Registres Internet Régionaux, selon les besoins. Ces allocations sont faites sous forme de blocs contigus alignés sur les bits de 2^24 adresses (aussi appelés préfixes /8). Les Registres Internet Régionaux (RIRs), à leur tour, allouent ou attribuent des blocs d'adresses plus petits aux Registres Internet Locaux (LIRs) ou aux Fournisseurs de Services Internet (ISPs). Ces entités peuvent utiliser directement l'attribution (comme c'est généralement le cas pour un ISP) ou peuvent effectuer de nouvelles sous-allocations d'adresses à leurs clients. Ces attributions d'adresses des RIR varient selon les besoins de chaque ISP ou LIR. Par exemple, un grand ISP pourrait se voir allouer un bloc d'adresses de 2^17 adresses (un préfixe /15), tandis qu'un ISP plus petit pourrait se voir allouer un bloc d'adresses de 2^11 adresses (un préfixe /21).
Notez que les termes « allocate » (allouer) et « assign » (attribuer) ont une signification précise dans le système de registre d'adresses Internet ; « allouer » renvoie à la délégation d'un bloc d'espace d'adressage à une organisation qui est censée effectuer de nouvelles sous-délégations, et « attribuer » est utilisé pour les sites qui utilisent directement (c'est-à-dire qui numérotent des hôtes individuels) le bloc d'adresses reçu.
Le tableau suivant fournit un raccourci pratique pour toutes les tailles de préfixe CIDR, indiquant le nombre d'adresses possibles dans chaque préfixe et le nombre de préfixes de cette taille qui peuvent être numérotés dans l'espace d'adressage IPv4 sur 32 bits :
notation addrs/block # blocks
-------- ----------- ----------
n.n.n.n/32 1 4294967296 "host route"
n.n.n.x/31 2 2147483648 "p2p link"
n.n.n.x/30 4 1073741824
n.n.n.x/29 8 536870912
n.n.n.x/28 16 268435456
n.n.n.x/27 32 134217728
n.n.n.x/26 64 67108864
n.n.n.x/25 128 33554432
n.n.n.0/24 256 16777216 legacy "Class C"
n.n.x.0/23 512 8388608
n.n.x.0/22 1024 4194304
n.n.x.0/21 2048 2097152
n.n.x.0/20 4096 1048576
n.n.x.0/19 8192 524288
n.n.x.0/18 16384 262144
n.n.x.0/17 32768 131072
n.n.0.0/16 65536 65536 legacy "Class B"
n.x.0.0/15 131072 32768
n.x.0.0/14 262144 16384
n.x.0.0/13 524288 8192
n.x.0.0/12 1048576 4096
n.x.0.0/11 2097152 2048
n.x.0.0/10 4194304 1024
n.x.0.0/9 8388608 512
n.0.0.0/8 16777216 256 legacy "Class A"
x.0.0.0/7 33554432 128
x.0.0.0/6 67108864 64
x.0.0.0/5 134217728 32
x.0.0.0/4 268435456 16
x.0.0.0/3 536870912 8
x.0.0.0/2 1073741824 4
x.0.0.0/1 2147483648 2
0.0.0.0/0 4294967296 1 "default route"
n est une valeur d'octet décimal sur 8 bits. Les liens point à point sont discutés plus en détail dans [RFC3021].
x est une valeur de 1 à 7 bits, basée sur la longueur du préfixe, décalée dans les bits de poids fort de l'octet et convertie en forme décimale ; les bits de poids faible de l'octet sont à zéro.
En pratique, des préfixes de longueur inférieure à 8 n'ont à ce jour été ni alloués ni attribués, bien que des routes vers de tels préfixes courts puissent exister dans les tables de routage si ou lorsqu'une agrégation agressive est effectuée. À la rédaction du présent document, aucune de ces routes n'est observée dans le système de routage global, mais des erreurs d'opérateur et d'autres événements ont conduit certaines d'entre elles (c'est-à-dire 128.0.0.0/1 et 192.0.0.0/2) à être observées dans certains réseaux à certains moments dans le passé.