Pourquoi le Groupe de travail sur l'ingénierie Internet (IETF) choisissent 192.168/16 pour être une classe d'adresse IP privée et non autre chose ?
Pourquoi spécifiquement 192.168/16 y 10/8 y 172.16/12 et non 145.243/16 par exemple ?
Y a-t-il une raison pour laquelle ces adresses IP ont été choisies comme norme pour les adresses IP privées parmi toutes les autres possibilités ?
Je sais qui a choisi ces plages d'adresses. Malheureusement, il est mort, donc je ne peux pas lui demander exactement warum il les a choisis, mais je peux faire quelques suppositions bien informées.
Il n'y a pas beaucoup de rencontres en ligne avant le milieu des années 1990, lorsque l'Internet a vraiment commencé à prendre son essor. L'histoire de l'Internet qui existe se trouve principalement dans le RFCs qui le définissent, qui remontent à 1969 au début de l'ARPANET. Grâce à eux, vous pouvez observer l'évolution d'Internet, qui est passé d'un réseau naissant composé de quelques ordinateurs centraux primitifs, conçus par certains des esprits les plus brillants de l'époque, à un réseau dont nous ne pouvons plus nous passer aujourd'hui.
Cette réponse s'inspire presque entièrement de ces RFC, et en petite partie de mon expérience personnelle, puisque j'étais sur Internet à cette époque.
Premièrement, l'IETF n'a pas choisi ces plages d'adresses IP, ni aucune autre. Attribution d'adresses à usage spécial est actuellement y a toujours été le travail de la Internet Assigned Numbers Authority .
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. Il est actuellement détenu par l'ICANN, mais de 1972 jusqu'à sa mort en 1998 Lorsque cette organisation a été créée pour le remplacer, l'IANA était essentiellement composée d'un seul homme, Jon Postel . Bien sûr, il a d'abord appelé le rôle le tsar des numéros de prises , a une tâche nécessaire qu'il a prise sur lui parce que ça devait être fait. Il a fini par devenir le tsar de pratiquement tous les numéros qui pouvaient être attribués : adresses, numéros de protocole, ports, et ainsi de suite, en grande partie parce qu'il était prêt à le faire, et au moment où l'Internet ouvert au commerce public il le faisait depuis plus de 20 ans. Il a attribué les numéros, et les Registre Internet (alors SRI-NIC, c'était élargi à un collection distribuée de registres dans le monde) les ont publiés.
Le dernier RFC de SRI montrant une liste d'assignations d'adresses Internet était le suivant RFC 1166 de 1990. Il s'agit d'une liste très longue, il n'est donc pas surprenant 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 montre le taux d'expansion de l'internet même à l'époque, des années avant son ouverture au public.
Donc, maintenant, nous sommes en mesure de comprendre les plages d'adresses en RFC 1918 un peu mieux. Il s'agit en fait de la deuxième révision de la RFC, la première étant la suivante RFC 1597 publié presque 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 d'adressage.
Ils ont été attribué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 par des voies détournées plutôt que par les processus ouverts habituels. Vous pouvez voir que le RFC 1597 lui-même est passé directement au statut de RFC sans le statut de RFC. habituel précédant Brouillons sur Internet Il a donc également été approuvé par des voies détournées, toujours par Postel, qui était également éditeur du RFC à l'époque . Il se peut donc qu'il ne soit jamais possible de répondre à cette question de manière concluante.
Quant à savoir pourquoi il a choisi ces trois plages d'adresses, permettez-moi de vous renvoyer aux RFC 1166 et 1117 du SRI qui contenaient les assignations de plages d'adresses IP en vigueur à l'époque. Dans ces deux documents, vous remarquerez que le réseau 10 était toujours attribué à l'équipe de l'OMPI. défunt ARPANET, qui avait fermé en 1990 . Postel, dans son rôle d'IANA, saurait que cette plage n'était plus utilisée et pouvait être réaffectée. Je postule que Postel a choisi le réseau 10 parce qu'il savait qu'il était disponible et non utilisé.
De même, je pense que Postel a choisi 192.168 parce que, au moment où il a fait son choix, c'était le prochain réseau disponible, ou presque, à être assigné à partir de l'ancien espace de la 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 RFCs suggère fortement qu'elles auraient été dans ce voisinage général autour de 1993-1994 quand les assignations ont été faites. (Les adresses de la zone 192.159 ont été attribuées en 1993-1994. en 1992 . Aucune date n'est disponible pour les assignations dans 192.160-192.167 car celles-ci ont été réattribuées à un moment donné à RIPE).
Répondre à cette question pour 172.16-172.31 est plus difficile. Rien de ce que j'ai pu trouver ne suggère pourquoi cette plage a été sélectionnée. Les assignations dans l'ancien espace de classe B n'étaient pas encore aussi élevées, d'après ce que j'ai pu découvrir. Je ne peux que spéculer que l'IANA a jeté une fléchette sur une cible, a lancé des dés ou a sorti ce nombre de ses régions inférieures.
Enfin, un mot sur Jon Postel. Malgré la manière apparente dont ce RFC a été mis en place sans contribution (initiale) de la communauté, je ne veux pas dire, et cela ne doit pas être interprété comme tel, que Jon Postel a en quelque sorte mal ou injustement rempli le rôle d'IANA. Il a été l'une des plus fortes influences sur les débuts de l'Internet, et vous ressentez encore cette influence aujourd'hui chaque fois que vous avez un aperçu de la machinerie des coulisses de l'Internet, mais il était toujours soucieux de faire le travail correctement. Pour citer un souvenir :
Il n'y a pas de gloire à faire de l'administration et des opérations. C'est plutôt le contraire. Les gens remarquent quand c'est mal fait mais font rarement des éloges quand c'est bien fait. Les personnes occupant des postes administratifs deviennent souvent des bureaucrates mesquins. Comme il y a si peu de récompense dans ce travail, ils en font artificiellement une base de pouvoir. Certains ont donc été déconcertés d'entendre Jon se faire appeler le "tsar" des numéros Internet. Ils ne se sont pas rendu compte que la communauté avait donné ce titre à Jon par affection et par profonde reconnaissance pour avoir mis de l'ordre dans les services d'infrastructure essentiels. En particulier, la communauté utilisait ce terme en sachant parfaitement que Jon prenait sa position comme une confiance, plutôt que comme une opportunité de pouvoir personnel. Nous avons toujours su que ses opinions étaient fondées sur des convictions légitimes et nous n'avons jamais eu à craindre qu'il cherche à tirer un avantage politique ou personnel. Nous pouvions ne pas être d'accord avec lui, mais nous avons toujours su qu'il était d'abord motivé par le souci de faire ce qui est juste.
Parce que ça avait du sens à l'époque ? :-D
Souvenez-vous, à l'époque de l'attribution des plages d'adresses IP privées, les ingénieurs réseau devaient faire face à plusieurs problèmes : Certains des routeurs les plus puissants de l'époque avaient à peu près autant de puissance CPU et de mémoire RAM que les calculatrices graphiques de poche d'aujourd'hui - et certains de ceux d'aujourd'hui tournent encore autour des routeurs d'antan (je me souviens de l'époque où la vitesse CPU était mesurée en kilohertz et où la mémoire RAM était mesurée en kilobytes, et non en giga* comme aujourd'hui !) L'Internet se développait rapidement, les IPv4 L'espace d'adressage était limité, et il semblait qu'il allait s'épuiser d'ici l'an 2000, etc. Par conséquent, de nombreuses plages d'adresses IP étaient déjà attribuées, et la Commission ne voulait pas avoir à demander aux entreprises de rendre les plages d'adresses IP pour pouvoir les réattribuer à des plages privées. Ils voulaient également faire en sorte qu'il soit aussi facile que possible pour les entreprises de travailler avec les plages privées - peu d'entreprises auraient coopéré si elles avaient dû investir beaucoup d'argent pour que leurs réseaux puissent s'adapter à une ou deux douzaines de plages/d'adresses IP ici et là.
Cette partie est certes une supposition de ma part, mais elle est largement basée 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 cherché un modèle distinctif qui répondait aux critères souhaités : Une seule adresse de classe A (les numéros de réseau qui ont un bit de poids fort de 0xxxxxxx binaire dans le numéro de réseau étaient de classe A), 16 adresses de classe B (numéros de réseau 10xxxxxx binaire), et 256 adresses de classe C (numéros de réseau 110xxxxxx binaire). Les adresses de classe B et C doivent toutes être consécutif également. (Le choix de 16 et 256 était probablement en partie arbitraire - après avoir fait ce genre de choses pendant un certain temps, on a tendance à commencer à penser en puissances de 2 - et probablement en partie parce que c'était ce que l'on pouvait trouver qui était ). disponible sur pour la réservation).
À partir de là, ils ont probablement sélectionné les plages finales parmi ces adresses disponibles, ce qui permettrait aux fabricants de routeurs d'effectuer un simple test binaire sur l'adresse pour déterminer s'il faut acheminer/transférer/abandonner le paquet. Il existe également certaines propriétés des modèles de bits qui peuvent aider à construire des tables NAT compactes. L'adresse 10.x.y.z est évidente, puisqu'elle ne doit correspondre qu'à un seul numéro de réseau. Les adresses 172.16.y.z à 172.32.y.z ont la particularité que si vous construisez une table avec les quatre bits de poids faible en référence croisée avec les quatre bits de poids fort, l'ensemble de la plage remplit une seule ligne de la table, sans se diviser en deux lignes - c'est-à-dire que le deuxième octet est toujours 0001xxxx (binaire). Dans 192.168.y.z, le binaire de 168 est 10101000, c'est-à-dire que les trois bits inférieurs sont toujours à 0 et les cinq bits supérieurs alternent entre 1 et 0.
Bien qu'ils puissent sembler arbitraires, si vous avez déjà fait de la programmation en langage machine ou du décodage de microcode, ces types de motifs vous permettent de tester seulement quelques bits pour déterminer le caractère privé ou public d'une adresse IP sans avoir à décoder toute l'adresse IP au préalable. Cela permettrait aux routeurs de traiter rapidement ces adresses sans avoir à maintenir en mémoire de vastes tables de consultation. Ainsi, le routeur pourrait renvoyer un paquet du réseau privé vers le réseau privé sans le décoder entièrement au préalable, ce qui permettrait de gagner de précieux cycles d'horloge sur la vitesse du routeur et du réseau.
Si vous êtes curieux, regardez comment la transmission de données en série (comme une carte de crédit) peut se faire. UART ) traite chaque octet de données : Il ne peut envoyer/recevoir qu'un seul bit à la fois, à la vitesse de l'horloge de contrôle, et encadre généralement les données par des bits supplémentaires tels que des bits de parité et de "synchronisation". Cela prendrait trop de temps d'essayer de calculer des choses comme la parité sur un octet entier en une fois, donc à la place, il maintient un bit spécial à chaque cycle d'horloge. Ce bit est modifié par le bit suivant qui entre/sort du registre d'envoi/réception. Dès que l'octet entier est envoyé/reçu, la valeur laissée dans le bit de parité est déjà correcte sans avoir à 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, elle calcule la parité en même temps qu'elle envoie/reçoit. Pour un routeur/switch, vous pouvez obtenir de meilleures performances s'il décode déjà l'adresse IP au fur et à mesure que chaque bit de l'adresse arrive sur le câble, et s'il sait déjà où envoyer le paquet suivant avant même qu'il ait fini d'être lu sur le câble réseau !
De plus, ce n'est qu'une question de logique ou de supposition de ma part, basée sur 25 ans de travail dans ce domaine. Je ne sais pas si nous connaîtrons un jour les raisons exactes qui se cachent derrière les chiffres définitifs choisis, car je ne me souviens pas qu'un document/RFC/etc. ait jamais donné le raisonnement complet. Les plus proches que j'ai vus sont juste quelques commentaires suggérant que les gammes choisies devraient permettre aux entreprises de les utiliser relativement facilement et efficacement avec un minimum d'effort/investissement/réingénierie.
Dans le Internet primordial le réseau maintenant dénommé 10.0.0.0/8 a été alloué au ARPANET . Lorsque l'IETF et l'IANA ont commencé à attribuer des plages d'adresses privées, ARPANET n'existait plus et son ancien espace d'adresses était disponible pour un usage privé.
Les deux autres gammes ont rendu les réseaux de classe B et de classe C disponibles pour les IP privés, en plus de la classe A susmentionnée.
Parce que 192 commence par 11xxxxxx en binaire, indiquant une classe C réseau. C'est le plus petit nombre qui commence par deux 1 consécutifs. Les classes A ont 0 comme bit(s) d'ordre supérieur et les classes B ont 10.
RFC 1918 qui définit les plages IP privées, ne clarifie pas ce point, il n'y a donc pas de réponse définitive sur la raison pour laquelle ils ont choisi .168 pour le bloc de 16 bits, mais je suppose que c'est parce que le RFC n'a pas été publié avant 1996, après qu'un grand nombre d'enregistrements aient déjà eu lieu. Comme 192 est le premier bloc de 8 bits dans les allocations de classe C, il est probable que beaucoup d'adresses étaient déjà prises. La 168 a pu être la première disponible.
Gardez également à l'esprit que certains de ces choix sont arbitraires. Notez que la gamme rfc1918 de classe B est 172.16 - 172.31 ? Je n'arrive pas à trouver la raison de l'existence de 172, mais je suis presque sûr qu'ils ont choisi d'utiliser 16 classes B pour avoir un bloc de 1 million d'adresses contiguës (1048576).
Pendant un certain temps, le noyau linux était limité à un maximum de 1024 CPU par système, et finalement ils ont dû publier un patch, après que certains superordinateurs aient eu 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 joli et rond.
C'est un vestige de Mise en réseau en classe où la gamme d'adresses IPv4 a été subdivisée en classes :
Depuis, nous sommes passés (en 1993) à Routage inter-domaines sans classe Cependant, les classes ont toujours leur héritage à différents 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 le matériel réseau plus "enterprisy", et multicast est toujours multicast.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
