2. Historique et Description du Problème (History and Problem Description)

Ce qui est maintenant connu sous le nom d'Internet a commencé comme un projet de recherche dans les années 1970 pour concevoir et développer un ensemble de protocoles qui pourraient être utilisés avec de nombreuses technologies de réseau différentes pour fournir une facilité transparente de bout en bout pour interconnecter un ensemble diversifié de systèmes terminaux.

Lorsqu'il a été déterminé comment l'espace d'adressage 32 bits serait utilisé, certaines hypothèses ont été faites concernant le nombre d'organisations à connecter, le nombre de systèmes terminaux par organisation et le nombre total de systèmes terminaux sur le réseau. Le résultat final a été l'établissement (voir [RFC791]) de trois classes de réseaux:

Classe A (Class A): bits d'adresse les plus significatifs '00', avec 128 réseaux possibles chacun avec 16,777,216 systèmes terminaux (moins les valeurs de bits spéciales réservées pour les adresses réseau/diffusion)
Classe B (Class B): MSB '10', avec 16,384 réseaux possibles chacun avec 65,536 systèmes terminaux (moins les valeurs réservées)
Classe C (Class C): MSB '110', avec 2,097,152 réseaux possibles chacun avec 254 systèmes terminaux (256 combinaisons de bits moins les modèles réservés tout-zéros et tout-uns)

L'ensemble d'adresses avec MSB '111' était réservé pour une utilisation future; des parties de celui-ci ont finalement été définies (MSB '1110') pour une utilisation avec la multidiffusion IPv4 (IPv4 Multicast) et des parties sont toujours réservées au moment de la rédaction de ce document.

À la fin des années 1980, l'expansion et la commercialisation de l'ancien réseau de recherche ont conduit de nombreuses nouvelles organisations à se connecter à l'Internet en croissance rapide, chaque nouvelle organisation nécessitant une allocation d'adresses selon le schéma d'adressage de classe A/B/C. Lorsque la demande de nouveaux numéros de réseau (en particulier l'espace de classe B) semblait montrer un taux de croissance exponentiel, certains membres de la communauté opérationnelle et d'ingénierie ont commencé à s'inquiéter des caractéristiques d'échelle à long terme du système de classe A/B/C et ont commencé à réfléchir à la manière de modifier les politiques d'allocation de numéros de réseau et les protocoles de routage pour s'adapter à la croissance.

En novembre 1991, l'Internet Engineering Task Force (IETF) a créé le groupe ROAD (Routing and Addressing) pour étudier la situation. Ce groupe s'est réuni en janvier 1992 et a identifié trois problèmes principaux:

L'épuisement de l'espace d'adressage réseau de classe B (Exhaustion of the Class B network address space): L'une des causes profondes de ce problème était l'absence d'une classe de réseau de taille appropriée pour les organisations de taille moyenne. La classe C avec un maximum de 254 adresses hôtes était trop petite, et la classe B, permettant jusqu'à 65,534 adresses hôtes, était trop grande pour la plupart des organisations, mais était le meilleur choix pour une utilisation avec le sous-réseau (Subnetting).
La croissance des tables de routage dans les routeurs Internet au-delà de la capacité du logiciel, du matériel et des personnes actuels à les gérer efficacement (Growth of routing tables in Internet routers beyond the ability of current software, hardware, and people to effectively manage).
L'épuisement éventuel de l'espace d'adressage IPv4 32 bits (Eventual exhaustion of the 32-bit IPv4 address space).

Compte tenu du taux de croissance d'Internet à l'époque, il était clair que les deux premiers problèmes deviendraient critiques à un moment donné entre 1993 et 1995. Les travaux existants sur l'allocation d'adresses topologiques pour le service de réseau sans connexion (CLNS, Connectionless Network Service) présentés à la communauté lors de la réunion IETF de Boulder en décembre 1990 ont guidé la réflexion sur la manière de restructurer l'espace d'adressage IPv4 32 bits pour prolonger sa durée de vie.

Les travaux au sein du groupe ROAD se sont poursuivis et ont finalement conduit à la publication de [RFC1338], suivie de [RFC1519].

La conception et le déploiement de CIDR visaient à résoudre ces problèmes en ralentissant la croissance de la table de routage globale (Global Routing Table) et en établissant un schéma d'allocation d'adresses basé sur la topologie avec une structure hiérarchique pour réduire le taux de consommation d'adresses IPv4.