2. Historique et description du problème

Historique et description du problème

Ce que l'on appelle aujourd'hui l'Internet a débuté dans les années 1970 comme un projet de recherche visant à concevoir et développer un ensemble de protocoles utilisables avec de nombreuses technologies de réseau différentes, afin de fournir une installation de bout en bout transparente pour l'interconnexion d'un ensemble diversifié de systèmes terminaux.

Lorsqu'il fut déterminé comment utiliser l'espace d'adressage sur 32 bits, certaines hypothèses furent faites quant au nombre d'organisations à connecter, au nombre de systèmes terminaux par organisation et au nombre total de systèmes terminaux sur le réseau. Le résultat final fut l'établissement (voir [RFC791]) de trois classes de réseaux : la classe A (bits de poids fort de l'adresse « 00 »), avec 128 réseaux possibles de 16777216 systèmes terminaux chacun (moins les valeurs de bits spéciales réservées pour les adresses réseau/diffusion) ; la classe B (bits de poids fort « 10 »), avec 16384 réseaux possibles de 65536 systèmes terminaux chacun (moins les valeurs réservées) ; et la classe C (bits de poids fort « 110 »), avec 2097152 réseaux possibles de 254 systèmes terminaux chacun (256 combinaisons de bits moins les motifs réservés tous à zéro et tous à un). L'ensemble des adresses dont les bits de poids fort sont « 111 » fut réservé pour un usage futur ; une partie de celles-ci fut finalement définie (bits de poids fort « 1110 ») pour un usage avec le multicast IPv4 et une partie reste encore réservée à la rédaction du présent document.

À la fin des années 1980, l'expansion et la commercialisation de l'ancien réseau de recherche entraînèrent la connexion de nombreuses nouvelles organisations à un Internet en rapide croissance, et chaque nouvelle organisation nécessitait une attribution d'adresses conforme au plan d'adressage de classe A/B/C.

Au moment où la demande de nouveaux numéros de réseau (particulièrement dans l'espace de classe B) prit un taux de croissance apparenté à une croissance exponentielle, certains membres de la communauté d'exploitation et d'ingénierie commencerent à s'inquiéter des propriétés d'évolution à long terme du système de classe A/B/C et commencerent à réfléchir à la manière de modifier la politique d'attribution des numéros de réseau et les protocoles de routage pour accommoder cette croissance. En novembre 1991, l'Internet Engineering Task Force (IETF) créa le groupe ROAD (Routing and Addressing) pour examiner la situation. Ce groupe se réunit en janvier 1992 et identifia trois problèmes majeurs :

Épuisement de l'espace d'adressage de réseau de classe B. Une cause fondamentale de ce problème est 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 d'hôtes, est trop petite, tandis que la classe B, qui permet jusqu'à 65534 adresses d'hôtes, est trop grande pour la plupart des organisations mais était la mieux adaptée disponible pour l'utilisation du sous-réseau.
Croissance des tables de routage dans les routeurs Internet au-delà de la capacité des logiciels, matériels et personnes actuels à les gérer efficacement.
Épuisement éventuel de l'espace d'adressage IPv4 sur 32 bits.

Il était clair que les taux alors actuels de croissance d'Internet feraient devenir critiques les deux premiers problèmes entre 1993 et 1995. Les travaux déjà en cours sur l'attribution topologique d'adressage pour le Connectionless Network Service (CLNS), présentés à la communauté lors de l'IETF de Boulder en décembre 1990, conduisirent à des réflexions sur la manière de restructurer l'espace d'adressage IPv4 sur 32 bits afin d'en accroître la durée de vie. Les travaux au sein du groupe ROAD suivirent et aboutirent finalement à la publication de [RFC1338], puis, plus tard, de [RFC1519].

La conception et le déploiement du CIDR visaient à résoudre ces problèmes en fournissant un mécanisme pour ralentir la croissance des tables de routage globales et réduire le taux de consommation de l'espace d'adressage IPv4. Il n'a pas et ne tente pas de résoudre le troisième problème, qui est d'une nature plus long terme ; à la place, il s'efforce d'atténuer suffisamment les difficultés à court et moyen terme pour permettre à l'Internet de continuer à fonctionner efficacement pendant que des progrès sont réalisés sur une solution à plus long terme.

Des éléments d'historique supplémentaires sur cet effort et sur le groupe ROAD peuvent être trouvés dans [RFC1380] et sur [LWRD].