IPv4

Un article de Wikipédia, l'encyclopédie libre
Aller à la navigation Aller à la recherche
Protocole Internet version 4
Pile de protocoles
IPv4 Packet-fr.svg
Paquet IPv4
Butprotocole d' interconnexion de réseaux
Développeur(s)DARPA
Introduction1981 ; il y a 41 ans ( 1981 )
InfluencéIPv6
Couche OSICouche réseau
RFC(s)791

Le protocole Internet version 4 ( IPv4 ) est la quatrième version du protocole Internet (IP). C'est l'un des protocoles de base des méthodes d'interconnexion de réseaux basées sur des normes dans Internet et d' autres réseaux à commutation de paquets . IPv4 a été la première version déployée pour la production sur SATNET en 1982 et sur ARPANET en janvier 1983. Il est encore utilisé pour acheminer la plupart du trafic Internet aujourd'hui, [1] même avec le déploiement en cours de la version 6 du protocole Internet (IPv6), [2 ] son ​​successeur.

IPv4 utilise un espace d'adressage de 32 bits qui fournit 4 294 967 296 (2 32 ) adresses uniques, mais de grands blocs sont réservés à des fins de mise en réseau spéciales. [3] [4]

Historique

La version 4 du protocole Internet est décrite dans la publication IETF RFC 791 (septembre 1981), remplaçant une définition antérieure de janvier 1980 (RFC 760). En mars 1982, le département américain de la Défense a choisi la suite de protocoles Internet (TCP/IP) comme norme pour tous les réseaux informatiques militaires. [5]

Objectif

Le protocole Internet est le protocole qui définit et permet l'interconnexion de réseaux au niveau de la couche Internet de la suite de protocoles Internet. Il forme essentiellement Internet. Il utilise un système d'adressage logique et effectue le routage , c'est-à-dire le transfert de paquets d'un hôte source vers le routeur suivant qui est un saut plus proche de l'hôte de destination prévu sur un autre réseau.

IPv4 est un protocole sans connexion et fonctionne sur un modèle de livraison au mieux , en ce sens qu'il ne garantit pas la livraison, ni n'assure un séquencement approprié ou l'évitement de la livraison en double. Ces aspects, y compris l'intégrité des données, sont traités par un protocole de transport de couche supérieure , tel que le protocole TCP ( Transmission Control Protocol ).

Adressage

Décomposition de la représentation de l'adresse IPv4 à quatre points en sa valeur binaire

IPv4 utilise des adresses 32 bits qui limitent l' espace d'adressage à 4 294 967 296 (2 32 ) adresses.

IPv4 réserve des blocs d'adresses spéciaux pour les réseaux privés (~18 millions d'adresses) et les adresses de multidiffusion (~270 millions d'adresses).

Représentations d'adresse

Les adresses IPv4 peuvent être représentées dans n'importe quelle notation exprimant une valeur entière de 32 bits. Ils sont le plus souvent écrits en notation point-décimal , qui se compose de quatre octets de l'adresse exprimés individuellement en nombres décimaux et séparés par des points .

Par exemple, l'adresse IP à quatre points 192.0.2.235 représente le nombre décimal 32 bits 3221226219, qui au format hexadécimal est 0xC00002EB.

La notation CIDR combine l'adresse avec son préfixe de routage dans un format compact, dans lequel l'adresse est suivie d'une barre oblique (/) et du nombre de bits 1 consécutifs de tête dans le préfixe de routage (masque de sous-réseau).

D'autres représentations d'adresses étaient d'usage courant lorsque la mise en réseau par classe était pratiquée. Par exemple, l'adresse de bouclage 127.0.0.1 s'écrit couramment 127.1 , étant donné qu'elle appartient à un réseau de classe A avec huit bits pour le masque de réseau et 24 bits pour le numéro d'hôte. Lorsque moins de quatre nombres sont spécifiés dans l'adresse en notation pointée, la dernière valeur est traitée comme un nombre entier d'autant d'octets qu'il est nécessaire pour remplir l'adresse jusqu'à quatre octets. Ainsi, l'adresse 127.65530 équivaut à 127.0.255.250 .

Attribution

Dans la conception originale d'IPv4, une adresse IP était divisée en deux parties : l'identifiant de réseau était l'octet le plus significatif de l'adresse et l'identifiant d'hôte était le reste de l'adresse. Ce dernier était aussi appelé le champ de repos . Cette structure permettait un maximum de 256 identifiants réseau, ce qui s'est rapidement avéré insuffisant.

Pour surmonter cette limite, l'octet d'adresse le plus significatif a été redéfini en 1981 pour créer des classes de réseau , dans un système qui est devenu plus tard connu sous le nom de réseau par classes . Le système révisé définissait cinq classes. Les classes A, B et C avaient des longueurs de bits différentes pour l'identification du réseau. Le reste de l'adresse a été utilisé comme précédemment pour identifier un hôte au sein d'un réseau. En raison des différentes tailles de champs dans différentes classes, chaque classe de réseau avait une capacité différente pour adresser les hôtes. En plus des trois classes d'adressage des hôtes, la classe D a été définie pour l' adressage multicast et la classe E a été réservée aux applications futures.

La division des réseaux par classe existants en sous-réseaux a commencé en 1985 avec la publication de la RFC 950 . Cette division a été rendue plus flexible avec l'introduction de masques de sous-réseau de longueur variable (VLSM) dans la RFC 1109 en 1987. En 1993, sur la base de ces travaux, la RFC 1517 a introduit le routage inter-domaine sans classe (CIDR), [6] qui exprimait le nombre de bits (du plus significatif ) comme, par exemple, /24, et le schéma basé sur les classes a été surnommé classful   , par contre. CIDR a été conçu pour permettre le repartitionnement de n'importe quel espace d'adressage afin que des blocs d'adresses plus petits ou plus grands puissent être alloués aux utilisateurs. La structure hiérarchique créée par le CIDR est gérée par l' Internet Assigned Numbers Authority (IANA) et les registres Internet régionaux (RIR). Chaque RIR maintient une base de données WHOIS consultable publiquement qui fournit des informations sur les attributions d'adresses IP.

Adresses à usage spécial

L' Internet Engineering Task Force (IETF) et l'IANA ont restreint l'utilisation générale de diverses adresses IP réservées à des fins particulières. [7] Ces adresses sont notamment utilisées pour le trafic multicast et pour fournir un espace d'adressage pour des utilisations illimitées sur des réseaux privés.

Blocs d'adresses spéciaux
Bloc d'adresse Plage d'adresses Nombre d'adresses Portée La description
0.0.0.0/8 0.0.0.0–0.255.255.255 16 777 216 Logiciel Réseau actuel [8]
10.0.0.0/8 10.0.0.0–10.255.255.255 16 777 216 Réseau privé Utilisé pour les communications locales au sein d'un réseau privé . [9]
100.64.0.0/10 100.64.0.0–100.127.255.255 4 194 304 Réseau privé Espace d'adressage partagé [10] pour les communications entre un fournisseur de services et ses abonnés lors de l'utilisation d'un NAT de classe opérateur .
127.0.0.0/8 127.0.0.0–127.255.255.255 16 777 216 Héberger Utilisé pour les adresses de bouclage vers l'hôte local. [8]
169.254.0.0/16 169.254.0.0–169.254.255.255 65 536 Sous-réseau Utilisé pour les adresses lien-local [11] entre deux hôtes sur un seul lien lorsqu'aucune adresse IP n'est autrement spécifiée, telle qu'elle aurait normalement été récupérée à partir d'un serveur DHCP .
172.16.0.0/12 172.16.0.0–172.31.255.255 1 048 576 Réseau privé Utilisé pour les communications locales au sein d'un réseau privé. [9]
192.0.0.0/24 192.0.0.0–192.0.0.255 256 Réseau privé Affectations de protocole IETF. [8]
192.0.2.0/24 192.0.2.0–192.0.2.255 256 Documentation Attribué comme TEST-NET-1, documentation et exemples. [12]
192.88.99.0/24 192.88.99.0–192.88.99.255 256 l'Internet Réservé. [13] Anciennement utilisé pour le relais IPv6 vers IPv4 [14] (inclut le bloc d'adresse IPv6 2002 ::/16 ).
192.168.0.0/16 192.168.0.0–192.168.255.255 65 536 Réseau privé Utilisé pour les communications locales au sein d'un réseau privé. [9]
198.18.0.0/15 198.18.0.0–198.19.255.255 131 072 Réseau privé Utilisé pour les tests de référence des communications inter-réseaux entre deux sous-réseaux distincts. [15]
198.51.100.0/24 198.51.100.0–198.51.100.255 256 Documentation Attribué comme TEST-NET-2, documentation et exemples. [12]
203.0.113.0/24 203.0.113.0–203.0.113.255 256 Documentation Attribué comme TEST-NET-3, documentation et exemples. [12]
224.0.0.0/4 224.0.0.0–239.255.255.255 268 435 456 l'Internet En cours d'utilisation pour la multidiffusion IP . [16] (Ancien réseau de classe D.)
233.252.0.0/24 233.252.0.0-233.252.0.255 256 Documentation Attribué comme MCAST-TEST-NET, documentation et exemples. [16] [17]
240.0.0.0/4 240.0.0.0–255.255.255.254 268 435 455 l'Internet Réservé pour une utilisation future. [18] (Ancien réseau de classe E.)
255.255.255.255/32 255.255.255.255 1 Sous-réseau Réservé à l' adresse de destination " diffusion limitée ". [8] [19]

Réseaux privés

Sur les quelque quatre milliards d'adresses définies dans IPv4, environ 18 millions d'adresses réparties en trois plages sont réservées à une utilisation dans des réseaux privés . Les adresses de paquets dans ces plages ne sont pas routables sur l'Internet public ; ils sont ignorés par tous les routeurs publics. Par conséquent, les hôtes privés ne peuvent pas communiquer directement avec les réseaux publics, mais nécessitent à cette fin une traduction d'adresse réseau au niveau d'une passerelle de routage.


Plages de réseau IPv4 privées réservées [9]
Nom Bloc CIDR Plage d'adresses Nombre d'adresses Description de classe
Bloc 24 bits 10.0.0.0/8 10.0.0.0 – 10.255.255.255 16 777 216 Classe A unique.
Bloc 20 bits 172.16.0.0/12 172.16.0.0 – 172.31.255.255 1 048 576 Gamme contiguë de 16 blocs de classe B.
Bloc 16 bits 192.168.0.0/16 192.168.0.0 – 192.168.255.255 65 536 Gamme contiguë de 256 blocs de classe C.

Étant donné que deux réseaux privés, par exemple deux succursales, ne peuvent pas interagir directement via l'Internet public, les deux réseaux doivent être pontés sur Internet via un réseau privé virtuel (VPN) ou un tunnel IP , qui encapsule les paquets, y compris leurs en-têtes contenant le adresses privées, dans une couche de protocole lors de la transmission sur le réseau public. De plus, les paquets encapsulés peuvent être chiffrés pour être transmis sur des réseaux publics afin de sécuriser les données.

Adressage

RFC 3927 définit le bloc d'adresse spécial 169.254.0.0/16 pour l'adressage lien-local. Ces adresses ne sont valides que sur le lien (tel qu'un segment de réseau local ou une connexion point à point) directement connecté à un hôte qui les utilise. Ces adresses ne sont pas routables. Comme les adresses privées, ces adresses ne peuvent pas être la source ou la destination des paquets traversant Internet. Ces adresses sont principalement utilisées pour la configuration automatique des adresses ( Zeroconf ) lorsqu'un hôte ne peut pas obtenir une adresse IP d'un serveur DHCP ou d'autres méthodes de configuration internes.

Lorsque le bloc d'adresses était réservé, aucune norme n'existait pour la configuration automatique des adresses. Microsoft a créé une implémentation appelée APIPA ( Automatic Private IP Addressing ), qui a été déployée sur des millions de machines et est devenue une norme de facto . Plusieurs années plus tard, en mai 2005, l' IETF a défini une norme formelle dans la RFC 3927, intitulée Dynamic Configuration of IPv4 Link-Local Addresses .

Bouclage

Le réseau de classe A 127.0.0.0 (réseau sans classe 127.0.0.0/8) est réservé au bouclage . Les paquets IP dont les adresses sources appartiennent à ce réseau ne doivent jamais apparaître en dehors d'un hôte. Les paquets reçus sur une interface sans bouclage avec une source de bouclage ou une adresse de destination doivent être supprimés.

Première et dernière adresses de sous-réseau

La première adresse d'un sous-réseau est utilisée pour identifier le sous-réseau lui-même. Dans cette adresse, tous les bits de l'hôte sont 0 . Pour éviter toute ambiguïté dans la représentation, cette adresse est réservée. [20] La dernière adresse a tous les bits d'hôte mis à 1 . Elle est utilisée comme adresse de diffusion locale pour envoyer simultanément des messages à tous les appareils du sous-réseau. Pour les réseaux de taille /24 ou supérieure, l'adresse de diffusion se termine toujours par 255.

Par exemple, dans le sous-réseau 192.168.5.0/24 (masque de sous-réseau 255.255.255.0), l'identifiant 192.168.5.0 est utilisé pour faire référence au sous-réseau entier. L'adresse de diffusion du réseau est 192.168.5.255.

Forme binaire Notation point-décimal
Espace réseau 11000000.10101000.00000101.00000000 192.168.5.0
Adresse de diffusion 11000000.10101000.00000101.11111111 192.168.5.255
En rouge, s'affiche la partie hôte de l'adresse IP ; l'autre partie est le préfixe du réseau. L'hôte est inversé (NON logique), mais le préfixe réseau reste intact.

Toutefois, cela ne signifie pas que chaque adresse se terminant par 0 ou 255 ne peut pas être utilisée comme adresse hôte. Par exemple, dans le sous-réseau /16 192.168.0.0/255.255.0.0, qui équivaut à la plage d'adresses 192.168.0.0–192.168.255.255, l'adresse de diffusion est 192.168.255.255. On peut utiliser les adresses suivantes pour les hôtes, même si elles se terminent par 255 : 192.168.1.255, 192.168.2.255, etc. De plus, 192.168.0.0 est l'identifiant du réseau et ne doit pas être attribué à une interface. [21] Les adresses 192.168.1.0, 192.168.2.0, etc., peuvent être attribuées, même si elles se terminent par 0.

Dans le passé, un conflit entre les adresses réseau et les adresses de diffusion survenait parce que certains logiciels utilisaient des adresses de diffusion non standard avec des zéros au lieu de uns. [22]

Dans les réseaux inférieurs à /24, les adresses de diffusion ne se terminent pas nécessairement par 255. Par exemple, un sous-réseau CIDR 203.0.113.16/28 a l'adresse de diffusion 203.0.113.31.

Forme binaire Notation point-décimal
Espace réseau 11001011.00000000.01110001.00010000 203.0.113.16
Adresse de diffusion 11001011.00000000.01110001.00011111 203.0.113.31
En rouge, s'affiche la partie hôte de l'adresse IP ; l'autre partie est le préfixe du réseau. L'hôte est inversé (NON logique), mais le préfixe réseau reste intact.

Dans un cas particulier, un réseau /31 a une capacité pour seulement deux hôtes. Ces réseaux sont généralement utilisés pour les connexions point à point. Il n'y a pas d'identifiant de réseau ni d'adresse de diffusion pour ces réseaux. [23]

Résolution d'adresse

Les hôtes sur Internet sont généralement connus par des noms, par exemple, www.example.com, et non principalement par leur adresse IP, qui est utilisée pour le routage et l'identification de l'interface réseau. L'utilisation des noms de domaine nécessite leur traduction, appelée résolution , en adresses et inversement. Cela revient à rechercher un numéro de téléphone dans un annuaire téléphonique en utilisant le nom du destinataire.

La traduction entre les adresses et les noms de domaine est effectuée par le système de noms de domaine (DNS), un système de nommage hiérarchique et distribué qui permet la sous-délégation d' espaces de noms à d'autres serveurs DNS.

Interface non numérotée

Une liaison point à point (PtP) non numérotée, également appelée liaison de transit, est une liaison qui n'a pas de réseau IP ou de numéro de sous-réseau associé, mais qui a toujours une adresse IP. Introduit pour la première fois en 1993. [24] [25] [26] [27] [28] Les seuls buts d'une liaison de transit sont d' acheminer les datagrammes .

Le lien non numéroté est utilisé pour libérer des adresses IP, lorsque l'espace d'adressage IP est limité, ou pour réduire la gestion de l'attribution des adresses IP et la configuration des interfaces. Auparavant, chaque lien doit être dédié au sous-réseau /30 ou /31 en utilisant 2 à 4 adresses IP par lien point à point. Lorsqu'un lien n'est pas numéroté, un identifiant de routeur est utilisé, l'identifiant de routeur est l'adresse IP /32 empruntée à une interface définie (normalement un bouclage ). Le même identifiant de routeur peut être utilisé sur plusieurs interfaces.

L'un des inconvénients de l'interface non numérotée est qu'il est plus difficile d'effectuer des tests et de la gestion à distance.

Phil Karn de Qualcomm est crédité en tant que designer original.

Épuisement de l'espace d'adressage

Depuis les années 1980, il était évident que le pool d'adresses IPv4 disponibles s'épuisait à un rythme qui n'était pas initialement prévu dans la conception originale du réseau. [29] Les principales forces du marché qui ont accéléré l'épuisement des adresses comprenaient le nombre croissant d'utilisateurs d'Internet, qui utilisaient de plus en plus des appareils informatiques mobiles, tels que des ordinateurs portables , des assistants numériques personnels (PDA) et des téléphones intelligents avec des services de données IP. De plus, l'accès Internet haut débit reposait sur des appareils toujours allumés. La menace d'épuisement a motivé l'introduction d'un certain nombre de technologies correctives, telles que:

Au milieu des années 1990, utilisation généralisée de la traduction d'adresses réseau (NAT) dans les systèmes des fournisseurs d'accès réseau et politiques d'allocation strictes basées sur l'utilisation dans les registres Internet régionaux et locaux.


Le pool d'adresses principal d'Internet, maintenu par l'IANA, a été épuisé le 3 février 2011, lorsque les cinq derniers blocs ont été alloués aux cinq RIR . [30] [31] APNIC a été le premier RIR à épuiser son pool régional le 15 avril 2011, à l'exception d'une petite quantité d'espace d'adressage réservée aux technologies de transition vers IPv6, qui doit être allouée dans le cadre d'une politique restreinte. [32]

La solution à long terme pour remédier à l'épuisement était la spécification de 1998 d'une nouvelle version du protocole Internet, IPv6 . [33] Il fournit un espace d'adressage considérablement accru, mais permet également une meilleure agrégation de routes sur Internet et offre de grandes allocations de sous-réseaux d'un minimum de 2 64 adresses hôtes aux utilisateurs finaux. Cependant, IPv4 n'est pas directement interopérable avec IPv6, de sorte que les hôtes IPv4 uniquement ne peuvent pas communiquer directement avec les hôtes IPv6 uniquement. Avec la suppression progressive du réseau expérimental 6bone à partir de 2004, le déploiement formel permanent d'IPv6 a commencé en 2006. [34] L'achèvement du déploiement d'IPv6 devrait prendre un temps considérable, [35]de sorte que des technologies de transition intermédiaires sont nécessaires pour permettre aux hôtes de participer à Internet en utilisant les deux versions du protocole.

Structure du paquet

Un paquet IP se compose d'une section d'en-tête et d'une section de données. Un paquet IP n'a pas de somme de contrôle de données ou tout autre pied de page après la section de données. En règle générale, la couche liaison encapsule les paquets IP dans des trames avec un pied de page CRC qui détecte la plupart des erreurs, de nombreux protocoles de couche transport transportés par IP ont également leur propre vérification des erreurs. [36]

En- tête

L'en-tête de paquet IPv4 se compose de 14 champs, dont 13 sont obligatoires. Le 14ème champ est facultatif et porte bien son nom : options. Les champs de l'en-tête sont emballés avec l'octet le plus significatif en premier ( big endian ), et pour le diagramme et la discussion, les bits les plus significatifs sont considérés comme étant les premiers ( MSB 0 bit numbering ). Le bit le plus significatif est numéroté 0, donc le champ de version se trouve en fait dans les quatre bits les plus significatifs du premier octet, par exemple.

Format d'en-tête IPv4
Décalages Octuor 0 1 2 3
Octuor Bit 0 1 2 3 4 5 6 7 8 9 dix 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Version DIH DSCP REC Longueur totale
4 32 Identification Drapeaux Décalage de fragments
8 64 Temps de vivre Protocole Somme de contrôle d'en-tête
12 96 Adresse IP source
16 128 Adresse IP de destination
20 160 Options (si DIH > 5)
56 448
Version
Le premier champ d'en-tête dans un paquet IP est le champ de version à quatre bits. Pour IPv4, c'est toujours égal à 4.
Longueur d'en-tête Internet (IHL)
L'en-tête IPv4 est de taille variable en raison du 14e champ facultatif (options). Le champ IHL contient la taille de l'en-tête IPv4 ; il a 4 bits qui spécifient le nombre de mots de 32 bits dans l'en-tête. La valeur minimale pour ce champ est 5, [37] ce qui indique une longueur de 5 × 32 bits = 160 bits = 20 octets. En tant que champ de 4 bits, la valeur maximale est 15 ; cela signifie que la taille maximale de l'en-tête IPv4 est de 15 × 32 bits = 480 bits = 60 octets.
Point de code des services différenciés (DSCP )
Initialement défini comme le type de service (ToS), ce champ spécifie des services différenciés (DiffServ) selon RFC 2474. [a] Le streaming de données en temps réel utilise le champ DSCP. Un exemple est la voix sur IP (VoIP), qui est utilisée pour les services vocaux interactifs.
Notification d'encombrement explicite (REC )
Ce champ est défini dans la RFC 3168 et permet une notification de bout en bout de la congestion du réseau sans perdre de paquets . ECN est une fonctionnalité facultative disponible lorsque les deux points de terminaison la prennent en charge et efficace lorsqu'elle est également prise en charge par le réseau sous-jacent.
Longueur totale
Ce champ de 16 bits définit la taille totale du paquet en octets, y compris l'en-tête et les données. La taille minimale est de 20 octets (en-tête sans données) et la taille maximale est de 65 535 octets. Tous les hôtes doivent pouvoir réassembler des datagrammes d'une taille allant jusqu'à 576 octets, mais la plupart des hôtes modernes gèrent des paquets beaucoup plus volumineux. Les liens peuvent imposer des restrictions supplémentaires sur la taille des paquets, auquel cas les datagrammes doivent être fragmentés . La fragmentation dans IPv4 est effectuée soit dans l'hôte d'envoi, soit dans les routeurs. Le réassemblage est effectué sur l'hôte de réception.
Identification
Ce champ est un champ d'identification et est principalement utilisé pour identifier de manière unique le groupe de fragments d'un seul datagramme IP. Certains travaux expérimentaux ont suggéré d'utiliser le champ ID à d'autres fins, telles que l'ajout d'informations de traçage de paquets pour aider à tracer les datagrammes avec des adresses source usurpées [38] , mais la RFC 6864 interdit désormais une telle utilisation.
Drapeaux
Un champ de trois bits suit et est utilisé pour contrôler ou identifier les fragments. Ce sont (dans l'ordre, du plus significatif au moins significatif) :
  • bit 0 : réservé ; doit être nul. [c]
  • bit 1 : Ne pas fragmenter (DF)
  • bit 2 : Plus de fragments (MF)
Si l'indicateur DF est défini et que la fragmentation est requise pour acheminer le paquet, le paquet est abandonné. Cela peut être utilisé lors de l'envoi de paquets à un hôte qui n'a pas de ressources pour effectuer le réassemblage des fragments. Il peut également être utilisé pour la découverte du chemin MTU , soit automatiquement par le logiciel IP hôte, soit manuellement à l'aide d'outils de diagnostic tels que ping ou traceroute .
Pour les paquets non fragmentés, le fanion MF est effacé. Pour les paquets fragmentés, tous les fragments sauf le dernier ont l'indicateur MF défini. Le dernier fragment a un champ Fragment Offset non nul, le différenciant d'un paquet non fragmenté.
Décalage des fragments
Ce champ spécifie le décalage d'un fragment particulier par rapport au début du datagramme IP non fragmenté d'origine en unités de blocs de huit octets. Le premier fragment a un décalage de zéro. Le champ de 13 bits autorise un décalage maximal de (2 13  – 1) × 8 = 65 528 octets, ce qui, avec la longueur d'en-tête incluse (65 528 + 20 = 65 548 octets), prend en charge la fragmentation des paquets dépassant la longueur IP maximale de 65 535 octets.
Durée de vie (TTL)
Un champ de durée de vie de huit bits limite la durée de vie d'un datagramme pour éviter une défaillance du réseau en cas de boucle de routage . Il est spécifié en secondes, mais les intervalles de temps inférieurs à 1 seconde sont arrondis à 1. En pratique, le champ est utilisé comme un nombre de sauts - lorsque le datagramme arrive sur un routeur , le routeur décrémente le champ TTL de un. Lorsque le champ TTL atteint zéro, le routeur rejette le paquet et envoie généralement un message ICMP de dépassement de temps à l'expéditeur.
Le programme traceroute envoie des messages avec des valeurs TTL ajustées et utilise ces messages de dépassement de temps ICMP pour identifier les routeurs traversés par les paquets de la source à la destination.
Protocole
Ce champ définit le protocole utilisé dans la partie données du datagramme IP. L'IANA tient à jour une liste des numéros de protocole IP conformément à la RFC 790.
Somme de contrôle d'en-tête
Le champ de somme de contrôle d' en-tête IPv4 16 bits est utilisé pour la vérification des erreurs de l'en-tête. Lorsqu'un paquet arrive à un routeur, le routeur calcule la somme de contrôle de l'en-tête et la compare au champ de somme de contrôle. Si les valeurs ne correspondent pas, le routeur rejette le paquet. Les erreurs dans le champ de données doivent être traitées par le protocole encapsulé. UDP et TCP ont des sommes de contrôle distinctes qui s'appliquent à leurs données.
Lorsqu'un paquet arrive à un routeur, le routeur diminue le champ TTL dans l'en-tête. Par conséquent, le routeur doit calculer une nouvelle somme de contrôle d'en-tête.
Adresse source
Ce champ est l' adresse IPv4 de l'expéditeur du paquet. Notez que cette adresse peut être modifiée en transit par un dispositif de traduction d'adresse réseau .
Adresse de destination
Ce champ est l' adresse IPv4 du destinataire du paquet. Comme pour l'adresse source, celle-ci peut être modifiée en transit par un dispositif de traduction d'adresse réseau.
Choix
Le champ des options n'est pas souvent utilisé. Les paquets contenant certaines options peuvent être considérés comme dangereux par certains routeurs et être bloqués. [39] Notez que la valeur dans le champ IHL doit inclure suffisamment de mots supplémentaires de 32 bits pour contenir toutes les options plus tout remplissage nécessaire pour garantir que l'en-tête contient un nombre entier de mots de 32 bits. Si IHL est supérieur à 5 (c'est-à-dire qu'il est compris entre 6 et 15), cela signifie que le champ des options est présent et doit être pris en compte. La liste d'options peut se terminer par une option EOOL (End of Options List, 0x00) ; cela n'est nécessaire que si la fin des options ne coïnciderait pas autrement avec la fin de l'en-tête. Les options possibles pouvant être placées dans l'en-tête sont les suivantes :
Domaine Taille (bits) La description
Copié 1 Défini sur 1 si les options doivent être copiées dans tous les fragments d'un paquet fragmenté.
Classe d'options 2 Une catégorie d'options générales. 0 correspond aux options de contrôle et 2 au débogage et à la mesure . 1 et 3 sont réservés.
Numéro d'option 5 Spécifie une option.
Longueur des options 8 Indique la taille de l'option entière (y compris ce champ). Ce champ peut ne pas exister pour les options simples.
Données d'options Variable Données spécifiques à l'option. Ce champ peut ne pas exister pour les options simples.
Le tableau ci-dessous montre les options définies pour IPv4. La colonne Type d'option est dérivée des bits Copié, Classe d'option et Numéro d'option comme défini ci-dessus. [40]
Type d'option (décimal / hexadécimal) Nom de l'option La description
0 / 0x00 EOOL Fin de la liste d'options
1 / 0x01 NON Pas d'opération
2 / 0x02 SECONDE Sécurité (défunte)
7 / 0x07 RR Enregistrer l'itinéraire
10 / 0x0A ZSU Mesure expérimentale
11 / 0x0B MTUP Sonde MTU
12 / 0x0C MTUR Réponse MTU
15 / 0x0F ENCODER ENCODER
25 / 0x19 QS Démarrage rapide
30 / 0x1E EXP Expérience de type RFC3692
68 / 0x44 TS Horodatage
82 / 0x52 TR Traceroute
94/0x5E EXP Expérience de type RFC3692
130 / 0x82 SECONDE Sécurité (RIPSO)
131 / 0x83 LSR Route source libre
133 / 0x85 E-SEC Sécurité étendue (RIPSO)
134 / 0x86 CIPSO Option de sécurité IP commerciale
136 / 0x88 SID ID de flux
137 / 0x89 RSS Route source stricte
142 / 0x8E VISA Contrôle d'accès expérimental
144 / 0x90 IMITD Descripteur de trafic IMI
145 / 0x91 EIP Protocole Internet étendu
147 / 0x93 ADDEXT Poste d'adresse
148 / 0x94 RTRALT Alerte routeur
149 / 0x95 SDB Diffusion dirigée sélective
151 / 0x97 DPS État de paquet dynamique
152 / 0x98 UMP Pkt de multidiffusion en amont.
158 / 0x9E EXP Expérience de type RFC3692
205 / 0xCD FINLANDAIS Contrôle de flux expérimental
222 / 0xDE EXP Expérience de type RFC3692

Données

La charge utile du paquet n'est pas incluse dans la somme de contrôle. Son contenu est interprété en fonction de la valeur du champ d'en-tête Protocol.

La liste des numéros de protocole IP contient une liste complète des types de protocoles de charge utile. Certains des protocoles de charge utile courants incluent :

Numéro de protocole Nom du protocole Abréviation
1 Protocole de message de contrôle Internet ICMP
2 Protocole de gestion de groupe Internet IGMP
6 Protocole de contrôle de transmission TCP
17 Protocole de datagramme utilisateur UDP
41 Encapsulation IPv6 ENCAP
89 Ouvrez le chemin le plus court en premier OSPF
132 Protocole de transmission de contrôle de flux SCTP

Fragmentation et réassemblage

Le protocole Internet permet le trafic entre les réseaux. La conception s'adapte aux réseaux de diverses natures physiques ; il est indépendant de la technologie de transmission sous-jacente utilisée dans la couche liaison. Les réseaux avec différents matériels varient généralement non seulement en vitesse de transmission, mais également en unité de transmission maximale (MTU). Lorsqu'un réseau veut transmettre des datagrammes à un réseau avec un MTU plus petit, il peut fragmenter ses datagrammes. Dans IPv4, cette fonction a été placée au niveau de la couche Internet et est exécutée dans les routeurs IPv4 limitant l'exposition à ces problèmes par les hôtes.

En revanche, IPv6 , la prochaine génération du protocole Internet, ne permet pas aux routeurs d'effectuer la fragmentation ; les hôtes doivent effectuer la découverte de MTU de chemin avant d'envoyer des datagrammes.

Fragmentation

Lorsqu'un routeur reçoit un paquet, il examine l'adresse de destination et détermine l'interface sortante à utiliser et la MTU de cette interface. Si la taille du paquet est supérieure à la MTU et que le bit Ne pas fragmenter (DF) dans l'en-tête du paquet est défini sur 0, le routeur peut fragmenter le paquet.

Le routeur divise le paquet en fragments. La taille maximale de chaque fragment est la MTU sortante moins la taille de l'en-tête IP (20 octets minimum ; 60 octets maximum). Le routeur place chaque fragment dans son propre paquet, chaque paquet de fragment ayant les modifications suivantes :

  • Le champ de longueur totale correspond à la taille du fragment.
  • L' indicateur more fragments (MF) est défini pour tous les fragments sauf le dernier, qui est défini sur 0.
  • Le champ de décalage de fragment est défini en fonction du décalage du fragment dans la charge utile de données d'origine. Ceci est mesuré en unités de blocs de 8 octets.
  • Le champ de somme de contrôle d'en-tête est recalculé.

Par exemple, pour un MTU de 1 500 octets et une taille d'en-tête de 20 octets, les décalages de fragment seraient des multiples de(0, 185, 370, 555, 740, etc.).

Il est possible qu'un paquet soit fragmenté sur un routeur et que les fragments soient encore fragmentés sur un autre routeur. Par exemple, un paquet de 4 520 octets, incluant un en-tête IP de 20 octets, est fragmenté en deux paquets sur une liaison avec un MTU de 2 500 octets :

Fragment Taille
(octets)
Taille de l'en- tête
(octets)
Taille des données
(octets)
Drapeau
Plus de fragments
Décalage de fragment
(blocs de 8 octets)
1 2 500 20 2 480 1 0
2 2 040 20 2 020 0 310

La taille totale des données est conservée : 2 480 octets + 2 020 octets = 4 500 octets. Les décalages sontet.

Lorsqu'il est transmis à un lien avec un MTU de 1 500 octets, chaque fragment est fragmenté en deux fragments :

Fragment Taille
(octets)
Taille de l'en- tête
(octets)
Taille des données
(octets)
Drapeau
Plus de fragments
Décalage de fragment
(blocs de 8 octets)
1 1 500 20 1 480 1 0
2 1 020 20 1 000 1 185
3 1 500 20 1 480 1 310
4 560 20 540 0 495

Là encore, la taille des données est conservée : 1 480 + 1 000 = 2 480 et 1 480 + 540 = 2 020.

Dans ce cas également, le bit More Fragments reste à 1 pour tous les fragments qui contiennent 1 et pour le dernier fragment qui arrive, cela fonctionne comme d'habitude, c'est-à-dire que le bit MF est mis à 0 uniquement dans le dernier. Et bien sûr, le champ Identification continue d'avoir la même valeur dans tous les fragments re-fragmentés. De cette façon, même si des fragments sont re-fragmentés, le récepteur sait qu'ils sont initialement tous partis du même paquet.

Le dernier décalage et la dernière taille de données sont utilisés pour calculer la taille totale des données :.

Remontage

Un récepteur sait qu'un paquet est un fragment, si au moins une des conditions suivantes est vraie :

  • Le drapeau plus de fragments est défini, ce qui est vrai pour tous les fragments sauf le dernier.
  • Le décalage de fragment de champ est différent de zéro, ce qui est vrai pour tous les fragments sauf le premier.

Le récepteur identifie les fragments correspondants à l'aide des adresses source et de destination, de l'ID de protocole et du champ d'identification. Le récepteur réassemble les données à partir de fragments avec le même ID en utilisant à la fois le décalage de fragment et l'indicateur plus de fragments. Lorsque le récepteur reçoit le dernier fragment, dont l' indicateur le plus de fragments est défini sur 0, il peut calculer la taille de la charge utile de données d'origine, en multipliant le décalage du dernier fragment par huit et en ajoutant la taille des données du dernier fragment. Dans l'exemple donné, ce calcul étaitoctets. Lorsque le récepteur a tous les fragments, ils peuvent être réassemblés dans le bon ordre en fonction des décalages pour former le datagramme d'origine.

Protocoles d'assistance

Les adresses IP ne sont pas liées de manière permanente au matériel réseau et, en effet, dans les systèmes d'exploitation modernes, une interface réseau peut avoir plusieurs adresses IP. Afin de livrer correctement un paquet IP à l'hôte de destination sur une liaison, les hôtes et les routeurs ont besoin de mécanismes supplémentaires pour établir une association entre l'adresse matérielle [c] des interfaces réseau et les adresses IP. Le protocole de résolution d'adresse (ARP) effectue cette traduction d'adresse IP en adresse matérielle pour IPv4. De plus, la corrélation inverse est souvent nécessaire. Par exemple, à moins qu'une adresse ne soit préconfigurée par un administrateur, lorsqu'un hôte IP est démarré ou connecté à un réseau, il doit déterminer son adresse IP. Les protocoles pour de telles corrélations inverses comprennentProtocole de configuration dynamique de l'hôte (DHCP), protocole d'amorçage (BOOTP) et, rarement, ARP inversé .

Voir aussi

Remarques

  1. ^ Mis à jour parRFC  3168 etRFC  3260
  2. ^ En tant que blague du poisson d'avril , proposée pour une utilisation dans la RFC 3514 en tant que " Evil bit "
  3. ^ Pourles technologies de mise en réseau IEEE 802 , y compris Ethernet , l'adresse matérielle est une adresse MAC .

Références

  1. ^ "Rapports d'analyse BGP" . Récupéré le 09/01/2013 .
  2. ^ "IPv6 – Google" . www.google.com . Récupéré le 28/01/2022 .
  3. ^ "Registre d'adresses à usage spécial IANA IPv4" . www.iana.org . Récupéré le 28/01/2022 .
  4. ^ "RFC 5735 - Adresses IPv4 à usage spécial" . datatracker.ietf.org . Récupéré le 28/01/2022 .
  5. ^ "Une brève histoire d'IPv4" . Groupe de marché IPv4 . Récupéré le 19/08/2020 .
  6. ^ "Comprendre l'adressage IP : tout ce que vous avez toujours voulu savoir" (PDF) . 3Com. Archivé de l'original (PDF) le 16 juin 2001.
  7. ^ Coton, M.; Vegoda, L. (janvier 2010). Adresses IPv4 à usage spécial . doi : 10.17487/RFC5735 . RFC 5735 .
  8. ^ un bcd M. Coton ; L. Vegoda; R. Bonica; B. Haberman (avril 2013). Registres d'adresses IP à usage spécifique . Groupe de travail sur l'ingénierie Internet . doi : 10.17487/RFC6890 . BCP 153. RFC 6890 . Mis à jour par RFC  8190 .
  9. ^ un bcd Y. Rekhter ; B. Moskowitz; D. Karenberg ; GJ de Groot; E. Lear (février 1996). Attribution d'adresses pour les Internets privés . Groupe de travail du réseau. doi : 10.17487/RFC1918 . PCA 5. RFC 1918 . Mis à jour par RFC  6761 .
  10. ^ J. Weil; V. Kuarsingh; C.Donley; C. Liljenstolpe; M. Azinger (avril 2012). Préfixe IPv4 réservé à l'IANA pour l'espace d'adressage partagé . Groupe de travail sur l'ingénierie Internet (IETF). doi : 10.17487/RFC6598 . ISSN 2070-1721 . BCP 153. RFC 6598 . 
  11. ^ S. Cheshire; B. Aboba ; E. Guttman (mai 2005). Configuration dynamique des adresses IPv4 Link-Local . Groupe de travail du réseau. doi : 10.17487/RFC3927 . RFC 3927 .
  12. ^ un bc J. Arkko ; M. Coton ; L. Vegoda (janvier 2010). Blocs d'adresses IPv4 réservés à la documentation . Groupe de travail sur l'ingénierie Internet . doi : 10.17487/RFC5737 . ISSN 2070-1721 . RFC 5737 . 
  13. ^ O. Troan (mai 2015). B. Carpenter (éd.). Dépréciation du préfixe Anycast pour les routeurs relais 6to4 . Groupe de travail sur l'ingénierie Internet . doi : 10.17487/RFC7526 . BCP 196. RFC 7526 .
  14. ^ C. Huitema (juin 2001). Un préfixe Anycast pour les routeurs relais 6to4 . Groupe de travail du réseau. doi : 10.17487/RFC3068 . RFC 3068 . Obsolète par RFC  7526 .
  15. ^ S. Bradner; J. McQuaid (mars 1999). Méthodologie d'analyse comparative pour les périphériques d'interconnexion réseau . Groupe de travail du réseau. doi : 10.17487/RFC2544 . RFC 2544 . Mis à jour par : RFC  6201 et RFC  6815 .
  16. ^ un b M. Coton; L. Vegoda; D. Meyer (mars 2010). Directives IANA pour les attributions d'adresses de multidiffusion IPv4 . Groupe de travail sur l'ingénierie Internet . doi : 10.17487/RFC5771 . BCP 51. RFC 5771 .
  17. ^ S. Venaas; R.Parekh; G. Van de Velde; T.Chown; M. Eubanks (août 2012). Adresses de multidiffusion pour la documentation . Groupe de travail sur l'ingénierie Internet . doi : 10.17487/RFC6676 . RFC 6676 .
  18. ^ J. Reynolds, éd. (janvier 2002). Numéros attribués : la RFC 1700 est remplacée par une base de données en ligne . Groupe de travail du réseau. doi : 10.17487/RFC3232 . RFC 3232 . Obsolète RFC  1700 .
  19. ^ Jeffrey Mogul (octobre 1984). Diffusion de datagrammes Internet . Groupe de travail du réseau. doi : 10.17487/RFC0919 . RFC 919 .
  20. ^ "RFC 923" . IETF . juin 1984 . Récupéré le 15 novembre 2019 . Adresses spéciales : dans certains contextes, il est utile d'avoir des adresses fixes ayant une signification fonctionnelle plutôt que comme identifiants d'hôtes spécifiques. Lorsqu'un tel usage est demandé, l'adresse zéro doit être interprétée comme signifiant "ceci", comme dans "ce réseau".
  21. ^ Robert Braden (octobre 1989). "Exigences pour les hôtes Internet - Couches de communication" . IETF . p. 31. RFC 1122 . 
  22. ^ Robert Braden (octobre 1989). "Exigences pour les hôtes Internet - Couches de communication" . IETF . p. 66. RFC 1122 . 
  23. ^ RFC 3021 
  24. ^ Almquist, Philippe; Kastenholz, Frank (novembre 1994). "Vers les exigences pour les routeurs IP" . {{cite journal}}:Citer le journal nécessite |journal=( aide )
  25. ^ RFC 1916 
  26. ^ RFC 1716 
  27. ^ RFC 1812 
  28. ^ "Comprendre et configurer la commande ip unnumbered" . Cisco . Récupéré le 25/11/2021 .
  29. ^ "Monde 'à court d'adresses Internet'" . Archivé de l'original le 2011-01-25 . Récupéré le 2011-01-23 .
  30. ^ Forgeron, Lucie; Lipner, Ian (3 février 2011). "Pool libre d'espace d'adressage IPv4 épuisé" . Organisation des ressources numériques . Récupéré le 3 février 2011 .
  31. ^ ICANN, liste de diffusion nanog. "Cinq /8s alloués aux RIR - il ne reste plus de /8s de monodiffusion IPv4 non alloués" .
  32. ^ Centre d'information du réseau Asie-Pacifique (15 avril 2011). "Le pool d'adresses IPv4 APNIC atteint la finale /8" . Archivé de l'original le 7 août 2011 . Récupéré le 15 avril 2011 .
  33. ^ Hinden, Bob; Deering, Steve E. (décembre 1998). "Protocole Internet, spécification de la version 6 (IPv6)" . tools.ietf.org . Récupéré le 13/12/2019 .
  34. ^ Fink, R.; HINden, R. (mars 2004). 6bone (allocation d'adresses de test IPv6) . doi : 10.17487/RFC3701 . RFC 3701 .
  35. ^ Conférence internationale IEEE 2016 sur les technologies émergentes et les pratiques commerciales innovantes pour la transformation des sociétés (EmergiTech) : date, 3-6 août 2016 . Université de technologie, Maurice, Institut des ingénieurs électriciens et électroniciens. Piscataway, NJ. 2016. ISBN 9781509007066. OCLC  972636788 .{{cite book}}: Maint CS1: autres ( lien )
  36. ^ Perdrix, C.; Kastenholz, F. (décembre 1994). "6.2 Somme de contrôle d'en-tête IP" . Critères techniques pour choisir IP The Next Generation (IPng) . p. 26. s. 6.2. doi : 10.17487/RFC1726 . RFC 1726 .
  37. ^ Postel, J. Protocole Internet . doi : 10.17487/RFC0791 . RFC 791 .
  38. ^ Sauvage, Stefan (2000). "Prise en charge pratique du réseau pour le traçage IP" . Examen de la communication informatique ACM SIGCOMM . 30 (4): 295–306. doi : 10.1145/347057.347560 . Récupéré le 06/09/2010 .
  39. ^ "FAQ non officielle de Cisco" . Récupéré le 10/05/2012 .
  40. ^ "Paramètres de la version 4 du protocole Internet (IPv4)" .

Liens externes