blog.title

Depuis les débuts des réseaux, les hôtes distants étaient identifiés par de courtes chaînes de caractères appelées noms de domainehttps://fr.wikipedia.org/wiki/Nom_de_domaine, ce qui évitait aux utilisateurs d'avoir à mémoriser laborieusement des adresses réseau numériques. Cet article traite de l'histoire et des détails de ces adresses, des débuts des années 70 à IPv4 et IPv6.

Historique

Lorsque l'ARPANET a relié les premiers réseaux entre eux, ils étaient interconnectés par des IMP, les ancêtres de la taille d'un réfrigérateur des routeurs actuels, situés à des positions clés et utilisant les lignes téléphoniques existantes. Les adresses dépendaient fortement de l'architecture, du système d'exploitation et du type de réseau, mais ces IMP permettaient à différents réseaux de communiquer entre eux, à condition qu'ils suivent le bon protocole RFC 1.

Les utilisateurs qui souhaitaient se connecter à un serveur distant utilisaient un terminal et établissaient une connexion en utilisant un nom d'hôte. Celui-ci était associé à une adresse d'un octet (8 bits) de long, dont les deux bits de poids fort désignaient le numéro d'hôte et les six bits de poids faible le numéro d'IMP. Cela permettait d'avoir 64 IMP, chacun avec un maximum de 4 hôtes, pour un total de 256 hôtes distincts, ce qui était considéré comme suffisant pour un avenir prévisible.

yyxxxxxx

À titre d'exemples d'adresses réseau, le tableau suivant liste les hôtes qui étaient disponibles en 1972 sur les quatre premiers IMP, parmi 35 déjà en service :

hostname	net addr	IMP	host	description
UCLA-NMC	1	1	0	UCLA, Network Measurement Center
UCLA-CCN	65	1	1	UCLA, Campus Computing Network
UCSD-CC	129	1	2	UCSD
SRI-ARC	2	2	0	SRI, Augmented Research Center
SRI-AI	66	2	1	SRI, Artificial Intelligence Group
UCSB-MOD75	3	3	0	UCSB
UTAH-10	4	4	0	University of Utah

IPv4

Inutile de dire qu'avec l'intérêt croissant et l'ajout de réseaux, un seul octet pour les adresses réseau n'était pas suffisant, et les travaux pour un remplacement ont commencé. Bien qu'il s'agisse d'un travail en cours depuis quelques années, au tournant de la décennie, en janvier 1980, le RFC 760 a proposé une meilleure alternative connue sous le nom d'IPv4.

Faisant partie de l’Internet Protocol, situé dans l’Internet layer de la suite de protocoles Internet, il a été officiellement mis en œuvre en 1983 et est rapidement devenu un pilier solide d'Internet.

Les adresses IPv4 faisaient quatre octets (32 bits) de long, le premier désignant le numéro de réseau. Cela permettait quatre fois plus de réseaux, 256, chacun avec jusqu'à 16 millions d'hôtes. Ces nouvelles adresses étaient quatre fois plus grandes que les précédentes et étaient considérées comme suffisantes pour un avenir prévisible.

xxxxxxxx yyyyyyyy yyyyyyyy yyyyyyyy

Classes d'adresses IP

Lorsqu'il est devenu évident l'année suivante qu'il n'y aurait pas assez de réseaux, IPv4 a été révisé avec le RFC 791. Il a divisé la même adresse 32 bits en différentes classes de réseau :

class	format	networks	hosts
A	0xxxxxxx yyyyyyyy yyyyyyyy yyyyyyyy	128	16M
B	10xxxxxx xxxxxxxx yyyyyyyy yyyyyyyy	16k	65k
C	110xxxxx xxxxxxxx xxxxxxxx yyyyyyyy	2M	256

L'idée était que les organisations et entreprises, au lieu de demander un numéro de réseau, demanderaient une classe de réseau adaptée à leurs besoins. Avec ce système à classes, plus de 2 millions de réseaux seraient disponibles.

Bien entendu, les réseaux existants ont été maintenus et ont conservé leurs numéros de réseau (classe A), même si la plupart étaient loin d'avoir besoin d'autant d'adresses IP.

Sous-réseaux

Internet est devenu de plus en plus populaire au milieu des années 1980 lorsque toutes les entreprises ont commencé à utiliser ce nouvel outil appelé courrier électronique. Il est rapidement devenu évident que même les classes de réseau ne suffiraient pas, et le RFC 950 a été publié en 1985 pour normaliser la façon dont un réseau devait se diviser en un nombre arbitraire de sous-réseaux, configurables facultativement à chaque niveau de réseau.

Par exemple, un réseau de classe B aurait pu décider de créer 16 sous-réseaux (quatre bits), soit 4 096 hôtes (12 bits) dans chaque sous-réseau :

10xxxxxx xxxxxxxx yyyyzzzz zzzzzzzz

Même si les sous-réseaux étaient limités à un réseau spécifique, il s'agissait toujours d'un changement important dans le fonctionnement du routage. Avant cela, les organisations qui voulaient différents réseaux, par exemple pour des bâtiments séparés, auraient besoin de plusieurs plages d'adresses IP. Si une organisation avait quatre bâtiments avec 1 000 hôtes chacun, elle aurait besoin de quatre réseaux de classe B et n'utiliserait que 4 000 adresses IP sur les ~260 000 qui seraient accessibles. Les sous-réseaux ont permis une utilisation plus efficace des plages d'adresses réseau, puisque cette même organisation pouvait maintenant subdiviser un seul réseau de classe B.

Problèmes imminents

Au début des années 1990, le RFC 1380 a été publié, expliquant certains problèmes qui nécessitaient une attention immédiate. En particulier, Internet était confronté à deux problèmes imminents et critiques :

• les réseaux de classe B allaient bientôt être épuisés ;
• les tables de routage devenaient trop volumineuses pour la technologie actuelle.

La source du premier problème était que dès 1992, à peine 10 ans après leur mise en œuvre, 54 % de la classe A et 43 % de la classe B étaient attribués. Comme les réseaux de classe A étaient trop grands et rarement attribués, et les réseaux de classe C trop petits pour une organisation typique, la classe B allait être épuisée.

Le deuxième problème était dû au fait qu'il fallait plus de temps, environ 18 mois, pour que les performances informatiques doublent, alors qu'Internet doublait de taille tous les 12 mois. Le matériel des routeurs ne pouvait tout simplement pas suivre longtemps.

Une aide a été apportée aux tables de routage avec le protocole Border Gateway, proposé en 1989 avec le RFC 1105 et mis en œuvre sur Internet vers 1994. Avec le BGP, tous les routeurs n'avaient pas besoin de conserver la table de routage complète. Cela permettait de transférer une plage de réseau plus large vers un autre routeur BGP, qui pouvait être affiné davantage à mesure qu'il s'approchait de sa destination.

Il y avait également un troisième problème, mais qui ne nécessitait pas d'attention immédiate comme les deux autres : la pénurie réelle d'adresses IPv4. Cela allait finir par arriver, donc la seule chose que quiconque pouvait faire était de ralentir le moment où cela se produirait.

Avec tout cela, le milieu des années 1990 était le moment où les ordinateurs étaient désormais abordables pour presque tout le monde. Atteignant désormais la plupart des autres pays, Internet était sur le point de connaître sa plus grande croissance à ce jour, exacerbant le besoin urgent de trouver un remplacement adéquat à IPv4.

CIDR

Le RFC 1517 a été publié en septembre 1993 décrivant le routage inter-domaine sans classe (Classless Inter-Domain Routing), ou CIDR, une mesure pour ralentir les problèmes mentionnés précédemment. Le CIDR a supprimé les anciennes plages de réseau à classes en faveur d'un nombre supplémentaire qui définissait combien de bits étaient réservés pour le préfixe réseau.

Le routage sur Internet nécessitait désormais cette information supplémentaire. Les plages IP non allouées, principalement de classe C à ce stade, pouvaient maintenant être attribuées avec plus de flexibilité, selon les besoins d'une organisation. Ce système permettait également de mieux agréger les adresses IP lors du routage, simplifiant les tables de routage.

Dans son essence, le CIDR n'est qu'un masque de bits. Par exemple, une valeur CIDR de 22 donnerait un masque de bits avec les 22 bits les plus élevés définis à 1, et le préfixe réseau pourrait être calculé en appliquant un ET logique entre l'adresse IP et le masque de bits :

    xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
AND 11111111 11111111 11111100 00000000
---------------------------------------
    xxxxxxxx xxxxxxxx xxxxxx00 00000000

NAT

La traduction d'adresses réseau (Network Address Translation), ou NAT, a été proposée en 1994 avec le RFC 1597. Avant cela, une entreprise avait besoin d'une adresse IP pour chaque ordinateur connecté à Internet. Le NAT a aidé en permettant à une passerelle NAT de mapper l'ensemble du réseau privé sur une seule adresse IP, en utilisant des numéros de port.

IPv6

Après quelques années, IPv6 a été proposé en décembre 1995 comme successeur d'IPv4 avec le RFC 1883, puis standardisé en 1998. Puisqu'il modifiait le protocole Internet, IPv4 et IPv6 ne sont pas rétrocompatibles, et un certain nombre de mécanismes ont été mis en œuvre au fil des ans pendant la lente transition qui se poursuit encore aujourd'hui.

Les adresses IPv6 font 16 octets de long (128 bits), dont la première moitié détermine l'identifiant de réseau et le sous-réseau, et le reste identifie l'hôte au sein du réseau. Cela donne 2^64 (près de deux quintillions) de réseaux, chacun avec autant d'hôtes possibles. C'est encore quatre fois plus grand qu'auparavant, et cela a été jugé suffisant, encore une fois, pour un avenir prévisible.

Format des adresses IP

Jusqu'à présent, seul le format interne des adresses IP a été mentionné. Une adresse IPv4 fait 4 octets (32 bits) de long, tandis qu'une adresse IPv6 fait 16 octets (128 bits). C'est ainsi qu'elles sont utilisées en interne par le matériel et les logiciels, juste une simple valeur entière, et c'est ainsi qu'elles devraient être conservées dans une base de données (pas comme une chaîne de caractères !). Encore mieux, chaque fois que possible, les fonctionnalités qu'une base de données offre pour les adresses IP devraient être utilisées. Par exemple, PostgreSQL dispose de types pour inet et cidr, ainsi que de fonctions qui peuvent être utilisées sur eux.

Cette valeur brute, par exemple 0x7f000001 pour l'adresse IPv4 localhost, n'est évidemment pas la façon dont elles doivent être représentées pour que les humains puissent les lire, et les sections suivantes montrent comment les adresses IP sont affichées et analysées.

Affichage des adresses IPv4

Une adresse IPv4 est affichée en séparant chaque octet, en décimal, par un point. C'est ce qu'on appelle la notation décimale à point. Puisque les zéros de tête ne sont pas affichés, chaque partie ira de 0 à 255. Par exemple, l'adresse IPv4 localhost est affichée comme 127.0.0.1.

Analyse des adresses IPv4

À partir de la notation décimale à point, il est facile d'analyser une chaîne en son adresse IPv4 : diviser la chaîne à chaque caractère ., convertir chaque partie en valeurs entières, les décaler du nombre approprié de bits, puis les additionner toutes ensemble.

La plupart des systèmes et outils utilisent inet_aton (et son inverse, inet_ntoa) pour convertir une chaîne en les 32 bits sous-jacents d'une adresse IPv4. inet_aton est une fonction de bibliothèque qui a été ajoutée au système d'exploitation BSD au milieu des années 1980 et qui a gagné en popularité dans d'autres systèmes d'exploitation.

Malheureusement, analyser la notation décimale pointée serait trop facile, et il existe en fait d'autres façons de fournir une chaîne d'adresse IPv4 qui peut être analysée dans sa représentation interne.

Expansion

Certaines parties peuvent être intentionnellement laissées vides. Lorsque cela se produit, la dernière partie est étendue pour remplir les parties manquantes. 127.0.1 est valide et est étendu en 127.0.0.1. La chaîne 10.0.4660 est étendue en 10.0.18.52.

D'où viennent le 18 et le 52 ? Il est plus facile d'utiliser l'hexadécimal pour illustrer ce qui se passe. Le nombre décimal 4660, en hexadécimal, s'écrit 1234. Puisque chaque octet correspond à deux chiffres hexadécimaux, les dernières parties deviennent donc 12 et 34, qui sont affichés en décimal comme 18 et 52.

En allant plus loin, 10.1193046 se développera en 10.18.52.86 et poussé à l'extrême, même la première partie peut être omise : 168965206 se développe également en 10.18.52.86.

Parfois, cela peut être considéré comme un raccourci pratique si l'application le permet, par exemple 127.1 pour localhost, ou 1.1 pour l'adresse IP DNS alternative de Cloudflare.

Autres bases

Les parties typiques d'une adresse IPv4 sont affichées en décimal, mais ce n'est pas toujours requis. Les adresses IPv4 peuvent être écrites en hexadécimal (0xa.0x12.0x34.0x56) et en octal (012.022.064.0126).

Cela est généralement lié à l'implémentation système qui convertit une chaîne en nombre, et c'est pourquoi c'est une mauvaise pratique d'afficher les adresses IP en décimal avec des zéros de remplissage, par exemple 010.018.052.086. Cela peut sembler joli dans une colonne d'adresses IP à espacement fixe, mais copier-coller ces adresses IP pourrait très bien les faire analyser en octal.

Confusion résultante

Pour aggraver les choses, tout cela peut être mélangé pour créer des monstruosités comme 10.022.0x3456, ce qui donne 10.18.52.86. C'est parce que la représentation des adresses IPv4 n'a jamais été normalisée, ce qui a conduit à des implémentations différentes et confuses au fil des ans.

Même si les différentes façons d'écrire les adresses IPv4 sont techniquement valides, il est fortement recommandé de n'utiliser que le format IPv4 typique en notation décimale à point. En prenant deux langages de programmation modernes comme exemple, Golang accepte tous les formats mentionnés ci-dessus, tandis que Rust n'accepte que le format "strict" en suivant les recommandations du RFC 6943.

Affichage des adresses IPv6

Contrairement aux adresses IPv4, IPv6 a défini une façon d'afficher ses adresses dès le début. Elle a été normalisée officieusement dans le RFC 5952 pour résoudre certaines confusions possibles.

Une adresse IPv6 est affichée comme huit groupes de deux octets en hexadécimal, séparés par des deux-points :

2001:db8::ff00:42:8329

L'exemple précédent utilise les deux règles suivantes pour raccourcir une représentation autrement beaucoup plus longue (2001:0db8:0000:0000:0000:ff00:0042:8329) :

1. Les zéros de tête dans un groupe n'indiquent pas une base différente et sont supprimés.
2. Les groupes consécutifs de 0000 sont remplacés par ::, mais une seule fois.

Exception en notation décimale à point

Il n'y a qu'une seule exception bien définie à ces règles, un format pour aider les systèmes dans un environnement mixte d'IPv4 et IPv6, avec les quatre derniers octets écrits en notation décimale pointée comme s'ils étaient une adresse IPv4 :

2001:db8::93.184.216.34

Analyse des adresses IPv6

L'analyse d'une chaîne d'adresse IPv6 typique est simple : diviser la chaîne par :, convertir chaque partie hexadécimale en valeurs entières, décaler chacune du nombre correct de bits, et les additionner toutes ensemble.

Comme pour IPv4, il existe des fonctions de bibliothèque liées aux adresses IPv6 : inet_pton et son inverse inet_ntop. inet_pton analyse une chaîne en une valeur IPv6 interne, et fonctionne également avec les adresses IPv4, bien que contrairement à inet_aton, celles-ci doivent être en notation décimale pointée.

Affichage du CIDR

Comme mentionné précédemment, la notation CIDR est utilisée comme masque de bits pour séparer le réseau et l'hôte. Lorsqu'elle est affichée avec une adresse IPv4 ou IPv6, elle suit directement l'adresse IP avec une barre oblique.

Par exemple, l'adresse IPv4 93.184.216.34 appartient à un réseau qui occupe 24 bits. Lorsqu'on parle de réseaux, elle s'affiche comme 93.184.216.0/24. L'adresse IPv4 198.202.90.193 est dans le réseau 198.202.64.0/18, ce qui indique que le réseau commence à 198.202.64.0 et se termine à 198.202.127.255.

Les adresses IPv6 avec notation CIDR sont affichées exactement de la même manière. 2001:db8::ff00:42:8329 est dans le réseau 2001:db8::/32, ce qui signifie que les 32 premiers bits représentent le numéro de réseau. Les adresses au sein de ce réseau vont alors de 2001:db8:: à 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff.

Affichage des numéros de port

Jusqu'à présent, seules les adresses IP ont été mentionnées. Au-dessus de la couche Internet se trouve la couche transport qui vient avec les numéros de port. Alors qu'une adresse IP cible un hôte, un numéro de port cible un processus sur cet hôte.

Lorsqu'un numéro de port est mentionné avec une adresse IPv4, ils sont affichés ensemble et séparés par un deux-points. Par exemple, 93.184.216.34:443 signifie le port 443 sur l'hôte situé à 93.184.216.34.

D'autre part, les adresses IPv6 sont affichées en utilisant le même caractère deux-points, donc pour éviter toute ambiguïté, l'adresse est placée entre crochets, par exemple [2001:db8::ff00:42:8329]:22 pour le port 22.

Attribution des adresses IP

Cette section donne un aperçu de la façon dont les adresses IP sont distribuées et comment l'utilisateur final en obtient une.

L'IANA

L'IANA est une organisation chargée d'attribuer les numéros Internet, y compris, le plus pertinent pour cet article, les adresses IP. Elle attribue des blocs d'adresses IPv4 et IPv6 aux 5 registres Internet régionaux (RIR), chacun gérant une région du monde : AFRINIC, APNIC, ARIN, LACNIC et RIPE NCC. Un RIR attribue ensuite des sous-blocs aux registres Internet locaux (LIR), qui sont des fournisseurs d'accès Internet (FAI), de grandes entreprises ou des institutions académiques.

Par exemple, l'IANA a attribué 2600::/12 à ARIN (un RIR) en décembre 2006, qui a ensuite attribué 2607:c000::/32 à Teksavvy (un LIR, mon FAI) en mars 2010.

Notez que certains RIR attribuent plutôt des blocs à des registres Internet nationaux (NIR), qui sont essentiellement des intermédiaires représentant un pays. Ces NIR attribuent ensuite des sous-blocs aux LIR.

Le FAI

Un FAI est une entreprise qui connecte les utilisateurs finaux à Internet. Comme vu précédemment, ils reçoivent des blocs d'adresses IP d'un RIR (ou NIR), qu'ils attribuent ensuite individuellement à leurs clients. Pour la plupart des clients résidentiels, cette adresse IP est dynamique et peut changer avec le temps. Les adresses statiques, en revanche, ne changent pas, mais doivent généralement être achetées. Celles-ci sont souhaitées par les entreprises qui sont accessibles depuis Internet, de peur qu'elles n'aient à reconfigurer leurs serveurs lorsque leur adresse IP change.

Le routeur

Lorsque le routeur d'un utilisateur est connecté au modem et allumé, il reçoit une adresse IP du serveur DHCP du FAI. Toutes les connexions entre le réseau derrière le routeur et Internet utiliseront cette adresse IP publique.

L'appareil

De la même manière que le routeur a reçu une adresse IP du FAI, un appareil connecté au réseau en reçoit une du routeur via DHCP. La différence est que cette adresse IP est privée au réseau derrière le routeur.

L'appareil n'a aucune idée de ce qu'est l'adresse IP publique. Pour la trouver, on doit interroger le routeur (généralement via son interface graphique) ou faire une requête à l'un des divers services, comme ip.me ou ifconfig.me. Ces deux services sont accessibles depuis un navigateur et le terminal via curl. Ils répondent simplement avec l'adresse IP publique de la requête.

Géolocalisation basée sur les adresses IP

Parce qu'un FAI opère généralement dans une région ou un pays, les adresses IP qu'un FAI attribue à ses clients peuvent donner une idée de l'endroit où l'utilisateur est situé.

Ce n'est qu'une supposition et cela ne fonctionne pas à chaque fois, mais c'est une façon dont fonctionne le géoblocage. Par exemple, disons qu'un serveur reçoit une requête de 93.184.216.34. Une simple requête RDAP montrera qu'elle appartient au réseau 93.184.216.0/24, enregistré à l'adresse suivante, et le serveur peut décider de bloquer la requête ou non :

EdgeCast Networks, Inc.
13031 W Jefferson Blvd
90094
Playa Vista CA
UNITED STATES

Un réseau privé virtuel (VPN) comme Mullvad ou ProtonVPN fonctionne en agissant comme intermédiaire entre un utilisateur et Internet. Le VPN effectue des requêtes au nom de l'utilisateur, donc le site web cible n'est pas au courant de l'utilisateur, mais voit plutôt l'emplacement du VPN. Notez que contourner les géoblocages peut parfois être illégal, et les connexions VPN peuvent être signalées par certains sites web (par exemple les banques) comme suspectes.

Adresses IP réservées

Cette section contient des adresses IP qu'il est parfois utile de connaître. Elle n'est pas du tout exhaustive, mais contient des liens qui peuvent être suivis pour plus d'informations.

Bouclage

L'adresse IP localhost, 127.0.0.1, est connue comme l'adresse de bouclage et se connecte à l'hôte lui-même. Moins connu est le fait qu'il s'agit en réalité de la plage 127.0.0.0/8, donc toute adresse IP commençant par 127 bouclera vers l'hôte, si le système et sa table de routage sont correctement configurés.

D'autre part, une seule adresse IPv6, ::1 (techniquement ::1/128) est réservée pour le bouclage.

Réseau privé

Certaines plages IP sont réservées aux réseaux privés. Les adresses IPv4 dans les plages suivantes sont pour le réseau actuel et ne seront pas routées vers Internet :

block	address range	class
10.0.0.0/8	from 10.0.0.0 to 10.255.255.255	class A
172.16.0.0/12	from 172.16.0.0 to 172.31.255.255	class B
192.168.0.0/16	from 192.168.0.0 to 192.168.255.255	class C

IPv6 a une énorme plage réservée pour un réseau privé, également appelée adresse locale unique : fc00::/7. Cela signifie que toutes les adresses IPv6 commençant par fc ou fd ne sont routables que dans le réseau privé actuel.

Adresse non spécifiée

Les adresses IP 0.0.0.0 et :: signifient une adresse non spécifiée. Elle a plusieurs significations différentes, mais elle est utile lors du démarrage d'un serveur, pour indiquer qu'il écoute les requêtes entrantes de toutes les adresses IP.

Documentation et exemples

Bien que le RFC 1166 mentionne certaines adresses IPv4 qui sont, ou étaient, destinées à la documentation et aux exemples, le RFC 3849 fait un meilleur travail en réservant toute la plage 2001:db8::/32.

Conclusion

Les adresses IP sont utilisées depuis plus de 40 ans. Leur histoire est un voyage dans le temps expliquant pourquoi et comment elles ont été modifiées et étendues pour répondre aux besoins d'un réseau planétaire en croissance.

Il est facile de rejeter ou de rire des décisions passées, mais celles-ci doivent être vues dans leur propre contexte. Les adresses réseau d'un octet peuvent sembler ridicules maintenant, mais elles proviennent d'une époque où les connexions étaient lentes et coûteuses. Seuls les centres de recherche, les universités et l'armée étaient censés avoir un jour une utilité pour les ordinateurs, qui étaient alors d'énormes appareils coûteux qui ne pouvaient être utilisés que pour la science.

IPv4 et ses nombreuses extensions proviennent du contexte d'un réseau en croissance exponentielle. Personne à cette époque ne pouvait prédire comment Internet serait utilisé par les entreprises, et encore moins par tout le monde à la maison.

Même si nous pourrions en théorie attribuer une adresse IPv6 à chaque atome de l'univers, le protocole a quand même été créé avant la popularité des appareils mobiles et IoT. Qui sait quel type de technologie ou de changement de paradigme pourrait apparaître dans cette décennie ou la suivante ? Nous pourrions être à une "connexion sécurisée utilisant des adresses uniques pour chaque paquet" ou des "adresses de qubits quantiques rotatives basées sur le temps" de réaliser que nous devons commencer à penser à la prochaine mise à niveau des adresses réseau. Après tout, si l'histoire nous a appris quelque chose, c'est que prévoir l'avenir n'est pas quelque chose dans lequel nous excellons.