Voir également l’article sur : Description du Protocole TCP/IP et Classes d’Adresses Réseaux Privés
Les protocoles TCP/IP ont été conçue pour transmettre les données à travers l’ARPANET, qui était un réseau à communications de paquets. Un paquet est un bloc de données qui véhicule avec lui l’information nécessaire pour qu’il soit délivré, comme une lettre de votre factrice préférée. Un réseau à commutation de paquets utilise l’information d’adressage située
dans les paquets pour commuter les paquets d’un réseau physique en un autre, vers leur destination finale. Chaque paquet se déplace à travers le réseau indépendamment des autres paquets.
Le datagramme est le format de paquet définit par le protocole IP. Les cinq ou six premiers mots de 32 bits de ce datagramme sont des informations de contrôle appelées en-tête. Par défaut, l’en-tête possède une taille de cinq mots. Le sixième est optionnel. Comme la taille de l’en-tête est variable, il inclut un champ appelé IHL (Internet Header Lenght) qui indique la taille de l’en-tête
en mots. L’en-tête du datagramme contient toutes les informations nécessaires à l’acheminement du paquet, c’est à dire du datagramme.
Par structure, le datagramme IP rappelle les trames utilisées dans les couches inférieures des protocoles réseau. Il est composé des données des couches supérieures, c’est a dire des données des applications contenues dans les messages TCP/UDP, précédées d’un en-tête comportant les informations de contrôle propre au protocole IP.
+--------+--------+---------+--------+
| En-tête | Données |
+--------+--------+---------+--------+ |
Le datagramme IP est véhiculé dans les trames des réseaux traversés. Par exemple, sur les réseaux Ethernet, les datagrammes sont en capsulés dans des trames Ethernet II, dont le champ type indique la valeur 0800.
+-------+-------+----+----+----+----+--------+--------+---+---+
| @destination | @source | 0800 | Datagramme IP | CRC |
+-------+-------+----+----+----+----+--------+--------+---+---+
| Trame Ethernet II |
+-------+-------+----+----+----+----+--------+--------+---+---+ |
Détaillons maintenant en-tête du datagramme représenté en cinq ou six mots de 32 bits (4 octets).
0 4 8 12 16 20 24 28 32
+--------+--------+--------+--------+--------+--------+--------+--------+
| Version| IHL | Type service | Longueur Total |
+--------+--------+--------+--------+--------+--------+--------+--------+
| Identification | FLAGS | Déplacement fragmentation |
+--------+--------+--------+--------+--------+--------+--------+--------+
| Durée de vie | Protocole | Somme de contrôle |
+--------+--------+--------+--------+--------+--------+--------+--------+
| Adresse IP source |
+--------+--------+--------+--------+--------+--------+--------+--------+
| Adresse IP destination |
+--------+--------+--------+--------+--------+--------+--------+--------+
| Options | Bourrage |
+--------+--------+--------+--------+--------+--------+--------+--------+
| Début de la zone de données |
+--------+--------+--------+--------+--------+--------+--------+--------+ |
Version
Le champ version contient sur 4 bits le numéro de version du protocole IP utilisé par le datagramme. Il permet aux équipements de vérifier le format et d’interpréter correctement la suite du datagramme. C’est d’ailleurs pour cette raison qu’il est placé au début. Une version inconnue par un équipement conduit au rejet du datagramme.
IP est actuellement implémenté en version 4 est IPV4, la version 5 est expérimentale et la version 6, appelée IP V6 existe.
Longueur d’en-tête - IHL
La longueur de l’en-tête est codée sur 4 bits et comptée en mots de 32 bits. Tous les champs sont de taille fixe, à l’exception du champ Option. Ce dernier est complété d’un champ bourrage pour donner un multiple de 32 bits.
Sans option, l’en-tête IP est composé de 5 mots de 32 bits. Avec des options, il peut varier de 6 a 15.
Type de service
Ce champ est composé de 6 sous-champs.
0 1 2 3 4 5 6 7 8
+-------+-------+-------+-------+-------+-------+-------+-------+
| Priorité | D | T | R | C |Inutil.|
+-------+-------+-------+-------+-------+-------+-------+-------+ |
La plupart des implémentations IP (stations et routeurs) ignorent le champ Type de service, qui prend dans ce cas la valeur 00000000.
Toutefois, il constitue un mécanisme intéressant pour assurer un meilleur acheminement des datagrammes.
La valeur Priorité permet d’indiquer l’importance du datagramme.
| 0 (000) |
Routine |
| 1 (001) |
Prioritaire |
| 2 (010) |
Immédiat |
| 3 (011) |
Urgent |
| 4 (100) |
Très urgent |
| 5 (101) |
Critique |
| 6 (110) |
Supervision interconnexion |
| 7 (111) |
Supervision réseau |
Les sous-champs D, T, R et C précisent des options désirées, mais non garanties.
Le sous-champ D précise le délai d’acheminement (Delay) :
| 0 |
Délai normal |
| 0 |
Délai court |
Le sous-champ T précise le débit de transmission (Throughput) :
| 0 |
Débit normal |
| 0 |
Débit élevé |
Le sous-champ R précise le niveau de fiabilité (Reliability) :
| 0 |
Niveau de fiabilité normal |
| 0 |
Niveau de fiabilité élevé |
Le sous-champ C précise le cout :
| 0 |
Cout normal |
| 0 |
Cout faible |
Le dernier bit n’est pas utilisé, il reste a 0. Il est qualifié de MBZ: Must Be Zero.
La description complète du champ Type de service est détaillé dans la RFC 1349.
Longueur du datagramme
La longueur du datagramme complet est exprimée en octets. Elle est codée sur 16 bits, ce qui permet d’indiquer une taille maximale de 216 soit 65535 octets. La longueur du champ données peut être obtenue en déduisant la longueur de l’en-tête
Le mécanisme de fragmentation
Le deuxième mot contient des informations nécessaires au mécanisme de fragmentation des datagrammes.
Pour comprendre le mécanisme de fragmentation, il faut d’abord se poser la question: quelle taille doit avoir un datagramme ?
Théoriquement, le datagramme est traité de manière logiciel et peut être de taille quelconque. Il n’est limité que par la taille du champ longueur, soit 65535 octets.
En pratique, le datagramme est acheminé dans des trames spécifiques aux réseaux de données traversés. L’idéal serait donc de pouvoir mettre un datagramme complet par trame. Hélas, ce n’est pas évident. En fonction des réseaux, les trames peuvent contenir une quantité maximale d’informations. Cette taille maximale est par exemple de 1500 octets sur les réseaux Ethernet et de 4470 octets sur les réseaux
FDDI. Cette limite est appelée Maximum Transfer Unit (MTU). Certaines MTU peuvent être très petites. Régler la taille des datagrammes IP sur la plus petite MTU des réseaux traversés n’est pas très efficace, notamment lorsque ce datagramme traverserait des réseaux a grande MTU. Ceci multiplierait le nombre de trames nécessaires. A l’inverse, si le datagramme est trop grand, il ne peut être contenu dans une
trame.
Le choix a été simple : plutôt que de tenir compte des particularités des réseaux physiques, les concepteurs du protocole IP ont choisi une taille initiale de 64 ko et ont mis en place un mécanisme permettent de découper les datagrammes en morceau lorsqu’ils doivent traverser un réseau a plus petite MTU. Le mécanisme est appelé fragmentation et les morceaux sont dénommés fragments.
En pratique, la taille initiale des datagrammes n’est pas toujours de 64 ko, mais elle peut être négociée au niveau de la connexion TCP. Par exemple, deux hôtes qui sont tout deux sur des réseaux Ethernet, négocieront une taille maximale de datagramme de 1500 octets.
Mais les deux hôtes ne connaissent pas les caractéristiques des réseaux traversés et il est fort probable que le datagramme soit amené a traverser un réseau a plus faible MTU et soit en conséquence fragmenté.
Prenons l’exemple d’un datagramme de 1500 octets avec un en-tête de 20 octets (5 mots de 32 bits). Pour traverser un réseau de MTU 500 octets, le datagramme sera fragmenté en morceaux de 500 octets, chacun avec l’en-tête IP de 20 octets.
___ ___ ___
___
| | | |
| P | | P |
|___ ___| MTU 1500 MTU 1500 |___ ___|
________|________ ________________ ________________ ________|________
| |
|________ ________|
| |
___|___ ___|___
| | MTU 1500 | |
| R |______________________| R |
|___ ___| |___ ___| |
Un rapide calcul nous donne :
1500 500 500 500 60
(20 + 1480) = (20 + 480 ) + (20 + 480) + (20 + 480) + (20 + 40)
Le datagramme sera donc fragmenté en 3 morceaux de 500 et un morceaux de 60 octets.
Que se passe-t-il si les fragments arrivent sur un réseau a plus grande MTU ?
On pourrait penser qu’il serait judicieux de réassembler les fragments pour les adapter à la MTU traversée. Pourtant le mécanisme serait complexe et il n’est pas certain que tous les fragments aient pris la même route et donc arrivent tous sur le même réseau. Que faire s’il manque un fragment ? Le choix est de ne réassembler les fragments qu’à l’arrivée, c’ est a dire sur l’hôte final, lorsque tous les fragments
sont arrivés.
Le deuxième mot de l’en-tête IP fournit les informations permettant de réassembler les fragments.
+-------+-------+-------+-------+-------+-------+-------+-------+
| Identification | | DF | MF | Offset |
+-------+-------+-------+-------+-------+-------+-------+-------+ |
D’abord il est nécessaire de bien identifier les fragments appartenant a un même datagramme. Il est possible que deux datagrammes soit envoyés entre les deux hôtes et que leurs fragments respectifs s’intercalent. Le couple (adresse IP Source, Adresse IP destination) n’est pas suffisant. Le champ identifiant fournit un numéro sur 16 bits commun a tous les fragments
d’un même datagramme.
Il faut ensuite les assembler dans l’ordre. Les fragments ont pu suivre des routes différentes et dans ce cas, n’arrivent pas nécessairement dans l’ordre. L’offset (ou décalage) fournit ainsi la position du fragment dans la datagramme d’origine, comptée en blocs de huit octets. Elle est indiquée sur 13 bits, ce qui donne bien une position en octets sur 213 * 8, soit 65535 octets. Dans notre exemple, les offsets prendront les valeurs
0, 60, 120 et 180.
Le bit MF ( More Fragment) est positionné a 1 pour tous les fragments sauf sur le dernier ou il est positionné a 0.
| Un datagramme non fragmenté est caractérisé par un offset de 0 et un bit MF également à 0. "Il est le premier et le dernier, donc il est seul". |
Le bit DF signifieDon’t Fragment. Lorsqu’il est positionné a 1, le datagramme ne peut pas être fragmenté. Si c’est nécessaire pour l’acheminement, il est écarté et détruit. Le bit DF n’est pas utilisé pour un transfert normal, mais pour l’administration des réseaux. En le positionnant et en modifiant la taille des datagrammes initiaux,
il est ainsi possible de connaître la plus petite MTU des réseaux traversés, à partir de la source.
Time To Live
Le troisième mot contient le champ TTL (Time To Live) qui indique le temps pendant lequel le datagramme peut circuler sur le réseau. Il est décrémenté de un lorsque le datagramme arrive sur un routeur traversé, puis a chaque seconde passée en attente au niveau de ce routeur.
Lorsque la durée de vie atteint la valeur 0, le routeur détruit le datagramme et envoie un message d’erreur a l’hôte qui l’a émis. La valeur initiale dépend des couches supérieures.
Son utilisation permet de détruire les datagrammes qui circuleraient en boucle lorsque les tables de routage sont corrompues.
Protocole
Le champ protocole de transport indique le type de protocole supérieur utilisé dans le message véhiculé (couche transport).
| 0 |
Réservé |
| 1 |
Internet Control Message Protocol (ICMP) |
| 2 |
Internet Group Management Protocol (IGMP) |
| 3 |
Gateway-to-Gateway Protocol (GGP) |
| 4 |
IP (IP encapsulation) |
| 5 |
Stream |
| 6 |
Transmission Control (TCP) |
| 8 |
Exterior Gateway Protocol (EGP) |
| 9 |
Private Interior Routing Protocol |
| 17 |
User Datagram (UDP)
|
| 89 |
Open Shortest Path First |
La liste complète des numéros est fournie dans la RFC 1340 : Assigned Numbers
Checksum - Somme de contrôle
Le checksum d’en-tête sur 16 bits est formé par le complément à 1 de la somme des mots de 16 bits de l’en-tête Pour le calcul, le champ Cheksum contient la valeur 0.
Ce contrôle ne porte que sur l’en-tête, ce qui offre l’avantage d’être particulièrement rapide, mais oblige les protocoles supérieurs à mettre en oeuvre leurs propres mécanismes de contrôle d’intégrité des données.
Enfin, le checksum doit être recalculé à chaque routeur, en fonction de la nouvelle valeur du TTL.
Adresses IP
Les quatrième et cinquième mots contiennent l’adresse IP source et l’adresse IP destination.
Options
Le sixième mot permet de préciser différentes options sous forme d’une liste. Il n’est pas obligatoire et n’est utilisé qu’à des fins de test ou de mise au point. Les options sont indiquées sous forme de code d’option sur un octet. Le code d’option est défini par trois sous-champs :
0 1 2 3 4 5 6 7 8
+-------+-------+-------+-------+-------+-------+-------+-------+
| Copie |Classe d’option| Numéro d’option |
+-------+-------+-------+-------+-------+-------+-------+-------+ |
Format de l’octet Code option Le bit Copie indique comment les options doivent être traitées lors de la fragmentation. Lorsqu’il est positionné à 1, il indique que les options doivent être recopiées dans chacun des fragments. Lorsqu’il est à 0, les options ne sont recopiées que dans le premier fragment.
La classe d’option et le numéro indiquent le type de l’option. Actuellement seules deux classes sont définies sur les quatre possibles : 0 pour la supervision des datagrammes et 2 pour les mises au point et mesures ; les classes 1 et 3 ne sont pas utilisées.
| Classe d’option |
Signification |
| 0 |
Datagramme ou supervision de réseau |
| 1 |
Réservé pour une utilisation future |
| 2 |
Mise au point et mesures |
| 3 |
Réservé pour une utilisation future |
| Classe d’option |
Numéro d’option |
Signification |
| 0 |
0 |
Fin de liste d’option. Utilisé si les options ne se terminent pas a la fin de l’en-tête (bourrage) |
| 0 |
1 |
Pas d’opération. Utilisé pour aligner les octets dans une liste d’options. |
| 0 |
2 |
Restriction de sécurité et de gestion. Destiné aux applications militaires. |
| 0 |
3 |
Routage lâche défini par la source. |
| 0 |
7 |
Enregistrement de route. |
| 0 |
8 |
Identificateur de connexion. |
| 0 |
9 |
Routage strict défini par la source. |
| 2 |
4 |
Horodatage dans l’internet. |
|
