Pourquoi l’IETF a-t-elle spécifiquement choisi 192.168 / 16 comme classe d’adresses IP privées?
Pourquoi le groupe de travail d'ingénierie Internet (IETF) a-t-il choisi 192.168/16 pour être une classe d'adresse IP privée et pas autre chose?
Pourquoi spécifiquement 192.168/16 et 10/8 et 172.16/12 et non pas 145.243/16 par exemple?
Existe-t-il une raison pour que ces adresses IP aient été choisies comme norme pour les adresses IP privées par rapport à toutes les autres possibilités?
Je sais qui a choisi ces plages d'adresses. Malheureusement, il est mort, je ne peux donc pas lui demander exactement pourquoi il les a choisis, mais je peux faire des suppositions bien éclairées.
Il n’y avait pas beaucoup de rencontres en ligne avant le milieu des années 90, quand Internet a vraiment commencé à décoller. L’histoire d’Internet existe principalement dans les RFC qui le définissent, qui remontent à 1969 , au début de l’ARPANET. Grâce à eux, vous pouvez regarder Internet évoluer d’un réseau naissant composé de quelques ordinateurs centraux primitifs conçus par certains des esprits les plus brillants de l’époque, jusqu’au réseau sans lequel nous ne pouvons imaginer vivre sans aujourd’hui.
Cette réponse s’appuie presque entièrement sur ces RFC, et en partie sur mon expérience personnelle, car j’étais sur Internet à cette époque.
Tout d'abord, l'IETF n'a pas choisi ces plages d'adresses IP, ni aucune autre. L'attribution d'adresses à usage spécial est actuellement et a toujours été le travail de l'autorité de numérotation assignée Internet .
L'IANA a toujours été un rôle , plutôt qu'une organisation spécifique, et ce rôle a changé de mains exactement une fois. Actuellement, il est détenu par l'ICANN, mais à partir de 1972 jusqu'à sa mort en 1998 lorsque cette organisation a été créée pour le remplacer, IANA était essentiellement un homme, Jon Postel . Bien sûr, il a d'abord appelé le rôle czar des numéros de socket , a tâche nécessaire qu'il s'est chargé car il fallait le faire . Il a fini par devenir le tsar de pratiquement tous les numéros pouvant être attribués: adresses, numéros de protocole, ports, nommez-le, en grande partie parce qu'il était disposé à le faire, et au moment où Internet ouvert au commerce public il le faisait depuis plus de 20 ans. Il a attribué les numéros et le Internet Registry (puis SRI-NIC, il s'agissait de développé en un collection de registres distribuée dans le monde entier) les a publiés.
La dernière RFC de SRI présentant une liste d’attributions d’adresses Internet était RFC 1166 datant de 1990. La liste est très longue. Il n’est donc pas étonnant que ces données aient été déplacées vers des bases de données en ligne. En le comparant à son prédécesseur RFC 1117 , le taux d'expansion de l'Internet est affiché même des années avant son ouverture au public.
Nous sommes donc maintenant en mesure de comprendre les plages d’adresses dans RFC 1918 un peu mieux. Ceci est en fait la deuxième révision de la RFC; le premier était RFC 1597 , publié près de deux ans plus tôt en mars 1994. Dans sa réfutation peu connue, RFC 1627 , les arguments contemporains contre les espaces d'adressage privés ont été exposés. La RFC 1627 mentionne également qui a attribué les trois espaces adresse.
Ils ont été assignés par l'IANA, c'est-à-dire Jon Postel, à la demande des auteurs du RFC 1597, et si l'on en croit la plainte du RFC 1627, il l'a fait via des canaux de retour plutôt que selon les processus ouverts habituels. Vous pouvez voir que la RFC 1597 elle-même est passée directement au statut RFC sans le habituel précédent Internet-Drafts , de sorte qu'elle a également été approuvée via les canaux de retour, toujours par Postel, qui était également éditeur RFC à l'époque . Donc, il pourrait ne jamais être possible de répondre à cette question de manière concluante.
Maintenant, pour ce qui est de la raison pour laquelle il a choisi ces trois plages d’adresses, permettez-moi de revenir à votre attention sur les RFC 1166 et 1117 de SRI, qui comportaient les attributions de plages d’adresses IP actuelles. Dans les deux cas, vous remarquerez que le réseau 10 était toujours attribué au defunct ARPANET, qui a été arrêté en 1990 . Postel, dans son rôle d’IANA, saurait que cette gamme n’est plus utilisée et peut être réaffectée. Je pense que Postel a choisi le réseau 10 car il savait qu'il était disponible et non utilisé.
De même, j'attends que Postel ait choisi 192.168, car, au moment où il a fait son choix, il s'agissait du prochain réseau disponible, ou presque, du prochain réseau disponible à être attribué à partir de l'ancien espace de classe C. Cela ne peut probablement pas être prouvé d'une manière ou d'une autre, mais le rythme des assignations d'adresses indiqué dans les RFC suggère fortement qu'elles se seraient trouvées dans ce voisinage général vers 1993-1994, au moment où les assignations ont été effectuées. (Des adresses dans 192.159 ont été attribuées en 1992 . Aucune date n'est disponible pour les assignations dans 192.160-192.167, celles-ci ayant été à un moment réallouées vers RIPE.)
Répondre à cette question pour 172.16-172.31 est plus difficile. Rien de ce que j'ai pu trouver n'indique pourquoi cette gamme a été sélectionnée. Les affectations dans l'ancien espace de classe B n'avaient pas encore atteint ce niveau, à ma connaissance. Je ne peux que spéculer sur le fait que l'IANA a lancé une fléchette sur un jeu de fléchettes, lancé des dés ou tiré d'une autre manière le numéro hors de ses régions inférieures.
Enfin, une note à propos de Jon Postel. Malgré l'apparence apparente avec laquelle cette RFC a été élaborée sans la participation (initiale) de la communauté, je ne veux pas dire que, et cela ne doit pas être interprété comme tel, Jon Postel a joué d'une manière ou d'une autre le rôle de l'IANA de manière mauvaise ou injuste. Il était l’une des influences les plus puissantes du début de l’Internet, et vous ressentez toujours cette influence aujourd’hui à chaque fois que vous avez un aperçu de la machinerie cachée d’Internet, mais il s’est toujours soucié de bien faire son travail. Pour citer de un souvenir :
Il n'y a pas de gloire dans l'administration et les opérations. Plutôt l'inverse. Les gens remarquent quand c'est mal fait mais font rarement l'éloge quand c'est bien fait. Les personnes occupant des postes administratifs deviennent souvent de petites bureaucrates. Comme il y a si peu de récompense dans le travail, ils en font artificiellement une base de pouvoir. Donc, il a confondu certains qui ont entendu Jon appelé les numéros Internet "czar". Ils ne se sont pas rendus compte que la communauté avait conféré le titre à Jon par sympathie et reconnaissance pour avoir mis de l'ordre dans les services d'infrastructure essentiels. En particulier, la communauté a utilisé ce terme en sachant que Jon considérait sa position comme une confiance, plutôt que comme une opportunité de pouvoir personnel. Nous avons toujours su que ses opinions découlaient de convictions légitimes et nous n'avons jamais eu à craindre qu'il envisageait en quelque sorte un avantage politique ou personnel. Nous ne sommes peut-être pas d’accord avec lui, mais nous avons toujours su que c’était d’abord le souci de faire ce qui est juste.
Parce que c'était logique à l'époque? :-RÉ
Rappelez-vous que, lorsque les plages d'adresses IP privées ont été attribuées, les ingénieurs réseau ont dû faire face à plusieurs problèmes: Certains des routeurs les plus puissants du moment disposaient d'environ autant de puissance de processeur et de RAM espace de stockage qu'aujourd'hui. des calculatrices graphiques - et certaines de celles-ci tournent toujours autour des routeurs des années précédentes (je me souviens quand la vitesse du processeur était mesurée en kilohertz et que la mémoire RAM était mesurée en kilo-octets, et non comme le giga * sont aujourd'hui!). Internet se développait rapidement, l’espace adresse IPv4 était limité et donnait l’impression qu’il allait s’épuiser d’ici à l’an 2000, et cetera. Ainsi, de nombreuses plages d'adresses IP ont déjà été attribuées et elles ne veulent pas avoir à demander aux entreprises de leur restituer les plages d'adresses IP simplement pour pouvoir les réaffecter à des plages privées. Ils souhaitaient également essayer de simplifier au maximum le travail des entreprises avec les gammes privées. Peu d'entreprises auraient coopéré si elles avaient dû investir beaucoup d'argent pour que leurs réseaux puissent gérer une ou deux douzaines de gammes/IP. adresses ici et là.
Cette partie est certes une conjecture de ma part, mais elle repose en grande partie sur la logique et l’expérience de la mise en place de réseaux. Ils ont probablement rassemblé une liste de tous les numéros de réseau non attribués et ont recherché un motif distinctif répondant aux critères souhaités: une seule classe. A (les numéros de réseau dont le bit binaire 0xxxxxxx est élevé dans le numéro de réseau étaient de classe A), 16 adresses de classe B (numéros de réseau 10xxxxxx binaires) et 256 adresses de classe C (numéros de réseau 110xxxx binaires). Les adresses de classe B et C doivent également être consécutives . (Le choix entre 16 et 256 était probablement en partie arbitraire - après l'avoir fait pendant un moment, vous avez tendance à commencer à penser avec une puissance de 2 - et probablement en partie parce que c'était ce que vous pouviez trouver disponible pour réservation.)
À partir de cela, ils ont probablement sélectionné les plages finales parmi les adresses disponibles, ce qui permettrait aux fabricants de routeurs d'effectuer un simple test bit par bit sur l'adresse afin de déterminer s'il convient d'acheminer/de transférer/de supprimer le paquet. Je peux également voir certaines propriétés des modèles de bits aidant à construire des tables compactes NAT. L'adresse 10.x.y.z est évidente, car elle ne doit correspondre qu'à un seul numéro de réseau. Les modèles 172.16.yz à 172.32.yz présentent le modèle suivant: si vous construisez une table avec les quatre bits de poids faible croisant les quatre bits de poids fort, l'intégralité de la plage se remplit sur une seule ligne de la table, sans se scinder en deux. --c'est-à-dire que le deuxième octet est toujours 0001xxxx (binaire). Dans 192.168.y.z, le binaire pour 168 est 10101000, c'est-à-dire que les trois bits inférieurs sont toujours 0 et que les 5 bits les plus élevés alternent 1 et 0.
Bien que ceux-ci puissent sembler arbitraires, si vous avez déjà effectué une programmation en langage machine ou un décodage de microcode, ces types de modèles vous permettent de ne tester que quelques bits pour effectuer une détermination privée/publique sans avoir à décoder d'abord l'adresse IP complète. Cela permettrait aux routeurs de traiter rapidement de telles adresses sans avoir à conserver de longues tables de recherche en mémoire. Ainsi, le routeur pourrait repousser un paquet d'un réseau privé vers le réseau privé sans le décoder au préalable, ce qui réduirait les cycles d'horloge précieux de la vitesse du routeur et du réseau.
Si vous êtes curieux, regardez comment la transmission de données en série (comme un UART ) traite chaque octet de données: elle ne peut qu'envoyer/recevoir Un seul bit à la fois, à la vitesse de l'horloge de contrôle, et encadre généralement les données dans des bits supplémentaires tels que des bits de parité et de "synchronisation". Il serait trop fastidieux d'essayer de calculer des éléments tels que la parité sur un octet entier à la fois. Elle conserve donc un bit spécial que chaque cycle d'horloge. Ce bit est modifié par le bit suivant qui est déplacé dans/hors du registre d'envoi/réception. Dès que tout l'octet est envoyé/reçu, la valeur laissée dans le bit de parité est déjà correcte sans qu'il soit nécessaire de la recalculer. Le concept est plus ou moins "faire le travail en même temps que vous faites autre chose", dans le cas d'une puce série, il calcule la parité en même temps qu'il envoie/reçoit. Pour un routeur/commutateur, vous pouvez obtenir de meilleures performances s’il décode déjà l’adresse IP car chaque bit de l’adresse provient du réseau, et sait peut-être déjà où envoyer le paquet avant même d’avoir fini de le lire depuis le réseau. câble!
En outre, cette IS est juste logique/conjecture de ma part, basée sur 25 ans de ce type de travail. Je ne sais pas si nous saurons un jour les raisons exactes des chiffres définitifs choisis, car je ne me souviens d'aucun article/RFC/etc. jamais donner la raison complète. Les commentaires les plus proches que j'ai vus ne sont que quelques commentaires suggérant que les gammes choisies devraient permettre aux entreprises de les utiliser relativement facilement et avec un minimum d'effort/investissement/restructuration.
Dans l’Internet primordial , le réseau noté 10.0.0.0/8 a été attribué à l’arpanet _ . Au moment où l’IETF et l’IANA ont décidé d’attribuer des plages d’adresses privées, ARPANET était morte et son ancien espace d’adresse était disponible pour un usage privé.
Les deux autres gammes offraient des réseaux de classe B et de classe C pour les adresses IP privées, en plus de la classe A susmentionnée.
Parce que 192 commence par 11xxxxxx en binaire, indiquant un réseau de classe C . C'est le nombre le plus bas qui commence par deux 1 consécutifs. Les classes de classe A ont le bit le plus élevé (0) et les classes de classe B en ont 10.
RFC 1918 qui définit les plages d’adresses IP privées, ne précise pas ce point. Il n’ya donc pas de réponse définitive quant aux raisons pour lesquelles ils ont choisi .168 pour le 16- Je pense que c’est parce que la RFC n’a pas été publiée avant 1996, alors qu’un très grand nombre d’enregistrements avaient déjà eu lieu. 192 étant le premier bloc de 8 bits dans les allocations de classe C, il est probable que de nombreuses adresses ont déjà été prises. 168 ont peut-être été les premiers disponibles.
Gardez également à l'esprit que certains de ces choix sont arbitraires. Notez que la plage de la classe B de rfc1918 est comprise entre 172.16 et 172.31? Je ne peux pas penser à la raison de 172, mais je suis à peu près sûr qu'ils ont choisi d'utiliser 16 classes B et qu'ils disposaient d'un bloc d'un million d'adresses contiguës (1048576).
Parfois, les protocoles ne sont que cela. quelqu'un devait faire un choix et ils l'ont fait. pendant un certain temps, le noyau Linux était limité à 1024 CPU maximum par système, et ils ont finalement dû publier un correctif, après que certains supercalculateurs eurent des problèmes. celui qui a décidé d'utiliser 1024 n'avait probablement aucune bonne raison de le faire si ce n'est qu'il avait besoin d'une valeur, et 1024 est agréable et rond.
Ceci est un vestige de réseau mis en réseau , où la plage d'adresses IPv4 a été subdivisée en classes:
- Classe A: 0.0.0.0 - 127.255.255.255/255.0.0.0
- Classe B: 128.0.0.0 - 191.255.255.255/255.255.0.0
- Classe C: 192.0.0.0 - 223.255.255.255/255.255.255.0
- Classe D: 224.0.0.0 - 239.255.255.255 (multidiffusion)
- Classe E: 240.0.0.0 - 255.255.255.255 (réservé)
Depuis, nous sommes passés (en 1993) à le routage interdomaine sans classe , mais les classes ont toujours leur héritage à divers endroits (le réseau 127 est "home/loopback" - 127.0 .0.1 quelqu'un?, 192.168.X est commun pour les routeurs domestiques, le réseau 10 est commun dans davantage de matériel réseau "d'entreprise", et la multidiffusion est toujours multidiffusion.
Le RFC explique la raison pour laquelle nous avons choisi trois gammes de "Classe A, B et C" respectivement: CIDR avait été spécifié mais n'avait pas été largement mis en œuvre. Il y avait une quantité importante d'équipement qui était encore "classe".
Pour autant que je me souvienne, le choix des gammes s’est fait comme suit:
10/8: l'ARPANET venait d'être éteint. L'un de nous l'a suggéré et Jon a considéré qu'il s'agissait d'une bonne réutilisation de ce bloc d'adresses "historique". Nous soupçonnions également que "net 10" aurait pu être codé en dur à certains endroits. Il pourrait donc être légèrement ré-utilisé pour un espace d'adressage privé plutôt que pour un routage inter-AS.
172.16/12: le plus bas des espaces non alloués/12 dans la classe B.
192.168/16: bloc le plus bas non alloué/16 de la classe C 192/8.
En résumé: l'IANA a alloué cet espace comme il le ferait pour tout autre but. En tant que responsable IANA, Jon était très constant à moins qu’il n’y ait vraiment de bonnes raisons d’être créatif.
Daniel (co-auteur de la RFC1918)